Атаки CSRF (міжсайтова підробка запиту) – це вебвразливість, яка дозволяє зловмиснику виконати підробний запит від імені користувача. Атаки CSRF також називаються XSRF, sea surf, session riding або one-click attack.
Серйозність:
Поширеність:
Сфера застосування:
Технічний вплив:
Наслідки в найгіршому випадку:
Швидке виправлення:
тяжка в рідкісних випадках
виявляється часто
вебдодатки з автентифікацією
зловмисник запускає неавторизовані дії
залежать від можливостей додатка
використання антиCSRF токенів
Як працюють атаки CSRF?
Більшість вебдодатків вимагають автентифікації, а деякі автентифіковані користувачі можуть виконувати дуже чутливі дії. Автентифікація у вебдодатках часто виконується на основі сеансів користувача. Після автентифікації браузер зберігає на комп’ютері сеансовий файл cookie і надсилає його з кожним запитом, який користувач робить до цього вебдодатку.
Рідше додатки можуть також використовувати NTLM або Basic Auth для автентифікації замість сеансових файлів cookie або навіть розпізнавати користувачів на основі їхніх IP-адрес.
Коли використовується додаток, багато HTTP-запитів, що надсилаються з браузера, є результатом явних дій, наприклад, коли вводиться URL-адреса в адресному рядку або відкривається посилання. Однак інші HTTP-запити надсилаються браузером неявно, оскільки він обробляє код, що міститься на поточній вебсторінці. Наприклад, якщо сторінка містить зображення, воно буде отримано окремим HTTP-запитом.
Такі неявні запити також можуть бути спрямовані на домени, які не мають нічого спільного з розташуванням сторінки, яку переглядають користувачі. Наприклад, зображення, що відображається на testinvicti.com, насправді може походити з example.com. У таких випадках важливо те, що запити до обох сайтів надходять з одного браузера. Саме тому поточний метод автентифікації (незалежно від того, чи це сеансовий файл cookie, чи інший метод) застосовується до обох сайтів. Отже, якщо браузер відкриває testinvicti.com і отримує зображення з example.com, створюючи таким чином сеанс користувача на example.com, вебдодаток example.com буде розглядати користувача як автентифікованого (навіть якщо спочатку було відкрито сайт testinvicti.com, а не example.com).
У поєднанні ці дві поведінки можуть бути використані для проведення атаки CSRF наступним чином:
- Користувач автентифікується в цільовому вебдодатку (наприклад, example.com).
- Зловмисник використовує соціальну інженерію, щоб обманом змусити користувача відвідати шкідливий вебсайт (наприклад, testinvicti.com).
- Шкідлива вебсторінка містить код (наприклад, тег зображення), який змушує браузер надсилати неявний запит до цільового сайту (наприклад, example.com).
- Шкідливий запит змушує ціль виконувати дії, які не були заплановані користувачем. Наслідки можуть відрізнятися залежно від програми
Слід зазначити, що CSRF раніше мала свою окрему категорію в OWASP Top 10 (наприклад, A5:2013). Однак, з розвитком більш ефективного AppSec і, відповідно, зменшенням впливу таких вразливостей, з 2017 року OWASP вирішив об’єднати CSRF в іншу, більш загальну категорію.
Типи атаки CSRF
CSRF вразливості можуть бути засновані на GET або POST запитах.
У випадку CSRF, заснованих на GET-запитах, зловмисник може просто використовувати тег зображення (або будь-який інший тег, який дозволяє виконувати міжсайтовий запит) на шкідливій сторінці.
Коли користувач відвідує сторінку із зазначеним тегом зображення (наприклад, після переходу за шкідливим посиланням), браузер користувача намагається відкрити зображення, але замість цього робить GET-запит до цільового сайту, таким чином виконуючи зловмисну дію під час входу в обліковий запис користувача. Якщо припустити, що користувач авторизований на example.com, вебдодаток не зможе відрізнити справжній запит користувача від зловмисного, оскільки вони обидва надсилаються з одного браузера.
У випадку CSRF на основі POST-запитів зловмиснику потрібно попрацювати трохи більше. Найпростіший спосіб провести таку атаку – змусити браузер користувача автоматично відправити форму за допомогою JavaScript.
Потенційні наслідки атаки CSRF запитів
У цьому типі атаки зловмисник ніколи не отримує HTTP-відповідь і тому не може використовувати цю техніку для безпосереднього зчитування/доступу до конфіденційної інформації. Він навіть не має доступу до значення сесійного файлу cookie, який надсилається разом зі зловмисним запитом.
Атака обмежена функціональністю вебзастосунка, або, точніше, тим, що застосунок дозволяє поточному користувачеві робити за допомогою запиту, що змінює стан. Наприклад, якщо використовується система продажу квитків, і поточний користувач може лише створювати та розв’язувати проблеми, то найбільше, чого може досягти зловмисник за допомогою CSRF, – це видалити чергу квитків. Наприклад, він не зможе отримати облікові дані адміністратора.
Цей тип атаки найбільш ефективний, коли спрямований на конкретну людину або невелику групу людей з високими привілеями. На відміну від міжсайтового скриптингу (XSS), часто немає сенсу надсилати шкідливе корисне навантаження CSRF великій кількості випадкових користувачів. Зазвичай CSRF ретельно готується, щоб скористатися перевагами конкретного користувача в компанії, наприклад, генерального директора, адміністратора або співробітника фінансового відділу.
Приклади відомих атак CSRF
Через природу CSRF не відомо про серйозні порушення, спричинені успішними CSRF-атаками. Однак в минулому було виявлено, що кілька популярних вебдодатків були вразливі до атак CSRF і могли бути використані в цілеспрямованих атаках:
- Netflix: У 2006 році, коли Netflix ще був сервісом прокату DVD-дисків, було виявлено CSRF-вразливість, яка дозволяла зловмиснику змінити облікові дані та повністю заволодіти акаунтом.
- ING: У 2008 році дослідники виявили CSRF-вразливості на сайті ingdirect.com, які дозволяли зловмиснику відкривати банківські рахунки від імені користувачів та переказувати кошти з їх рахунків.
- WordPress: У 2020 році дослідники виявили, що 25 популярних плагінів WordPress мають CSRF-вразливості.
Це лише кілька прикладів з багатьох, і хоч невідомо про якісь жахливі наслідки цих вразливостей, не виключено, що вони були використані для індивідуально спрямованих атак, які просто не потрапили до ЗМІ.
Як виявити вразливості CSRF?
Найкращий спосіб виявлення CSRF-вразливостей залежить від того, чи вони вже відомі, чи ще невідомі.
Якщо використовуються лише комерційні або вебдодатки з відкритим кодом і не розробляються власні вебдодатки, то може бути достатньо визначити точну версію додатка, який використовується користувачем. Якщо ідентифікована версія є вразливою до CSRF, можна припустити, що вебсайт є вразливим. Можна визначити версію вручну або скористатися відповідним інструментом безпеки, наприклад, рішенням для аналізу складу програмного забезпечення (SCA).
Якщо при розробці власних вебдодатків хочеться знаходити CSRF-вразливості, потрібно мати можливість успішно експлуатувати CSRF-вразливість, щоб бути впевненими в її існуванні. Для цього потрібно або виконати мануальне тестування на проникнення за допомогою дослідників безпеки, або скористатися інструментом тестування безпеки (сканером), який може використовувати автоматизацію для експлуатації вебвразливостей. Прикладами таких інструментів є Invicti та Acunetix.
Як запобігти Cross-Site Request Fraud в вебдодатках?
Основним методом захисту від CSRF-атак є створення способу для вебдодатка відрізняти легітимні запити (зроблені від імені цього додатку) від потенційно зловмисних (відправлених додатком під зовнішнім впливом). Наступні два методи є найбільш ефективними та широко використовуваними.
Токени Anti-CSRF
Цей метод захисту ґрунтується на надсиланні спеціального маркера з кожним легітимним запитом і обов’язковій перевірці цього маркера при отриманні запитів. Цей антиCSRF токен, який іноді називають токеном синхронізатора, генерується на стороні сервера, і зловмисники не мають можливості дізнатися його правильне значення – воно відоме лише вебпрограмі та браузеру. Запити, надіслані як спроби CSRF-атаки, не матимуть дійсного токена, що дозволяє програмі ігнорувати їх як недійсні, реєструвати їх як спроби атаки або навіть підіймати тривогу.
Після того, як згенерується антиCSRF маркер, його можна буде включити в приховане поле форми або автоматично додавати в спеціальний заголовок для кожного запиту. Слід пам’ятати, що антиCSRF маркери слід використовувати не лише для кожної форми в авторизованій зоні вебзастосунка, але й для неавторизованих форм входу, API та AJAX-запитів (XMLHttpRequest).
Існує багато бібліотек для безпечної генерації та перевірки антиCSRF токенів за допомогою криптографічних методів. Наприклад, Paragonie anti-CSRF для PHP та GDS anti-CSRF для Java. Краще використовувати такі бібліотеки замість того, щоб намагатися створювати власний код, який буде більш схильний до помилок і складніший в підтримці.
Також слід звернути увагу, що хоча багато сучасних фреймворків розробки вже мають вбудовані токени синхронізаторів, їх захист від CSRF часто обмежується методами HTTP, які призначені для запитів, що змінюють стан. Це означає, що GET-запити, як правило, не охоплюються. Тому, якщо розробник створює функції зміни стану, які отримують вхідні дані від GET-запитів, що є дуже поганою практикою програмування, ці запити не будуть покриватися вбудованим CSRF-захистом.
Файли cookie SameSite
Ще один дуже ефективний спосіб відрізнити легітимні запити від потенційно шкідливих – це подивитися на походження запиту. Можна з впевненістю припустити, що якщо запит надходить з того ж домену/сайту, то він, швидше за все, легальний. Якщо ж він надходить із зовнішнього домену, він може бути шкідливим. Щоб скористатися цим методом, можна використати спеціальний прапорець безпеки файлів cookie.
Сучасні браузери підтримують атрибут файлів cookie SameSite, який можна використати при налаштуванні сесійних файлів cookie. Він може мати одне з трьох значень:
- Слабкий: Браузер не надсилає файли cookie для міжсайтових під запитів, наприклад, для завантаження зображень або фреймів на сторонній сайт, але надсилає файли cookie, коли користувач переходить за посиланням.
- Суворий: Браузер надсилає файли cookie тільки в контексті першого сайту (first-party) і взагалі не надсилає їх при запитах, ініційованих сторонніми вебсайтами.
- Жодного: Браузер надсилає файли cookie в усіх контекстах, але необхідно також встановити атрибут безпеки, інакше браузер заблокує файли cookie.
Хоча більшість сучасних браузерів за замовчуванням встановлюють атрибут SameSite на Lax для всіх файлів cookie, краще все одно встановити його вручну у вебдодатку (на Lax або Strict, залежно від того, чи потрібні міжсайтові під запити, чи ні). Це на випадок, якщо є користувачі зі старими версіями браузерів, в яких за замовчуванням встановлено значення SameSite на None.
На жаль, якщо це єдиний метод, який застосовується для захисту користувачів від CSRF, невелика кількість користувачів застарілих браузерів, таких як Internet Explorer, які взагалі не підтримують файли cookie SameSite, залишатимуться вразливими до CSRF-атак.
Інші методи захисту
Хоча токени синхронізатора і файли cookie SameSite вважаються найкращими методами захисту від CSRF, існують і інші способи відрізнити легітимні запити від потенційно зловмисних. Деякі розробники, наприклад, використовують заголовок referer, щоб виявити цю різницю. Інші намагаються реалізувати захист на основі таких механізмів, як політика однакового походження (policy of same-origin), яка є неефективною проти CSRF.
Хоча такі методи, як виявлення рефералів, можуть бути ефективними, вони не настільки надійні, як токени проти CSRF. Краще не використовувати будь-які інші методи, окрім токенів синхронізатора та файлів cookie SameSite, бажано разом.
Як захиститися від атак CSRF?
Найкращий спосіб захиститися від CSRF-атак – переконатися, що всі користувачі використовують сучасні, повністю оновлені веббраузери, які підтримують файли cookie SameSite. Це дозволить вебдодаткам використовувати файли cookie SameSite як основний захист від CSRF. Своєю чергою, розробникам не доведеться впроваджувати будь-які засоби захисту в код вебдодатків (оскільки всі файли cookie за замовчуванням налаштовані на Lax).
Можна посилити захист, відключивши доступ до вебдодатків для браузерів, які не підтримують файли cookie SameSite. Однак цей метод може мати негативний вплив на користувачів (наприклад, він заблокує всіх користувачів Internet Explorer), тому його слід застосовувати з обережністю.
