Що таке CSRF і як захистити застосунок
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: CSRF — це атака, за якої сторонній сайт спонукає браузер авторизованого користувача надіслати небажаний запит до іншого сервісу. Якщо сервіс перевіряє лише те, чи користувач увійшов в обліковий запис, він може виконати операцію без його свідомої згоди. Основа захисту — засоби на боці застосунку: токени CSRF, належні налаштування файлів cookie та перевірка походження запитів.
Як працює CSRF — приклад із панеллю магазину
CSRF — скорочення від Cross-Site Request Forgery, тобто підроблення міжсайтових запитів. Атака використовує те, що браузер може автоматично додавати сесійний файл cookie до запитів, спрямованих до певного сервісу. Такий файл cookie дає серверу змогу розпізнати авторизованого користувача, не запитуючи пароль повторно.
Уявіть, що ви керуєте інтернет-магазином і маєте відкриту панель адміністратора. В іншій вкладці ви відвідуєте сторінку, підготовлену зловмисником. Ця сторінка намагається надіслати до панелі запит на зміну адреси електронної пошти, прив’язаної до вашого облікового запису.
Якщо браузер додасть сесійний файл cookie, а панель додатково не перевірить справжність запиту, сервер може сприйняти його як ваше рішення. Зловмиснику не потрібно знати пароль або читати файл cookie — достатньо, щоб браузер використав його під час надсилання запиту.
Це схоже на ситуацію, коли хтось передає на виконання розпорядження з вашою автоматично проставленою печаткою. Система розпізнає печатку, але не перевіряє, чи справді ви хочете виконати саме цю операцію.
Коли атака може вдатися і що їй не заважає
Для типової атаки CSRF потрібні кілька умов: користувач має активну сесію, браузер автоматично надсилає дані автентифікації, а застосунок приймає передбачуваний запит, який змінює стан облікового запису. Це може бути зміна даних, додавання користувача або видалення запису. Наслідки залежать від доступних операцій і прав жертви.
Зловмиснику зазвичай не потрібно читати відповідь сервера. Браузер може заборонити сторонньому сайту читати дані з панелі, але надсилання деяких запитів усе одно залишається можливим. Тому політика однакового походження, яка обмежує доступ скриптів до чужих ресурсів, не замінює захисту від CSRF.
HTTPS також не розв’язує цієї проблеми. Він шифрує з’єднання та захищає дані під час передавання, але не підтверджує, що користувач свідомо доручив виконати операцію. Самого використання методу POST замість GET теж недостатньо: сторонній сайт може надіслати звичайну форму POST.
CSRF — не те саме, що XSS. XSS полягає у виконанні небажаного коду в контексті довіреного сайту, тоді як CSRF використовує довіру сервісу до запитів із браузера користувача. Проте вразливість XSS може підірвати захист від CSRF, наприклад давши змогу прочитати токен.
Як захистити застосунок від CSRF
Найбезпечніше почати з вбудованого захисту фреймворку, яким ви користуєтеся. Його потрібно ввімкнути й переконатися, що він охоплює всі операції зміни даних, а не лише форму входу.
- Перевіряйте токен CSRF. Це непередбачуване значення, яке застосунок додає до форми або передає для надсилання у відповідному заголовку. Сервер перевіряє його перед виконанням операції. У поширеному варіанті токен пов’язаний із сесією; сторонній сайт не повинен мати змоги прочитати чи вгадати його. Токен не має потрапляти до адреси URL.
- Задайте атрибут SameSite для сесійного файлу cookie. Він обмежує надсилання файлу cookie в міжсайтових взаємодіях. Варіанти Lax і Strict забезпечують різний рівень обмежень, тому потрібно перевірити, як обраний варіант працює зі входом та інтеграціями. SameSite — це додатковий рівень захисту, а не безумовна заміна токена.
- Перевіряйте походження запиту. Заголовок Origin, а в належно спроєктованому механізмі також Referer, допомагає визначити, звідки надійшов запит. Порівнюйте його значення з точно визначеними дозволеними адресами, а не шукайте лише фрагмент доменного імені.
- Не змінюйте дані через GET. Відкриття посилання не повинно видаляти обліковий запис чи підтверджувати замовлення. Операції зміни даних мають використовувати відповідні методи й так само проходити перевірку CSRF.
Для особливо чутливих дій додайте повторну автентифікацію або окреме підтвердження. Сесійні файли cookie також повинні мати відповідні атрибути Secure і HttpOnly, хоча жоден із них сам по собі не запобігає CSRF.
Чи потребує API захисту?
API, тобто інтерфейс для взаємодії між програмами, також може бути вразливим до CSRF, якщо використовує сесію з автентифікацією через файл cookie. Сама відповідь у форматі JSON не гарантує безпеки.
Коли клієнт явно додає токен доступу в заголовку Authorization, а браузер не додає його автоматично, типовий механізм CSRF зазвичай не спрацьовує. Однак це не означає захищеності від викрадення токена чи XSS. CORS, тобто механізм, що регулює доступ між різними джерелами походження, теж не є самостійним захистом від CSRF.
Що перевірити у власному сервісі
Почніть з однієї операції, наприклад зміни адреси електронної пошти. На тестовому обліковому записі, у власному середовищі або з дозволу власника перевірте, чи відхиляється запит без токена CSRF або з неправильним токеном і чи справді він не змінює даних. Потім перевірте налаштування файлу cookie та інші шляхи виконання тієї самої операції.
Якщо ви користуєтеся готовою системою, перевірте, як працює захист, в офіційній документації відповідної версії та встановлених розширень. Як користувач ви не можете виправити відсутність захисту на сервері; проте можете зменшити ризик, виходячи з облікового запису після роботи з панеллю, що надає доступ до чутливих даних або дій. Як власник застосунку почніть із перегляду операцій зміни даних — саме для них потрібно перевіряти, чи запит справді надходить з інтерфейсу, якому дозволено виконувати ці операції.
Дивіться також: Що означає www?
Читайте також
