Авторка: Катерина Іваненко, Invicti Brand Manager
Що таке CSRF?
Підробка міжсайтових запитів (CSRF) – це тип атаки на вебзастосунки, коли зловмисник змушує браузер автентифікованого користувача виконати небажану дію на довіреному вебсайті.
Злочинець створює зовнішній ресурс (як-от вебдодаток, допис на форумі), який надсилає запит на цільовий сайт від імені користувача.
Оскільки браузер автоматично додає файли cookie автентифікації, сервер не може визначити, чи є запит легітимним чи підробленим.
В результаті зловмисники можуть примусово виконати серйозні дії: зміну паролів, оновлення адрес електронної пошти, переказ коштів, зміну налаштувань облікового запису тощо.
Якщо цей користувач має права адміністратора, атака може призвести до повної компрометації вебзастосунку.
Як захиститися від CSRF: ключові методи
Нижче наведено найефективніші методи запобігання CSRF, рекомендовані OWASP та іншими авторитетними джерелами.
1. Анти-CSRF токени
Найбільш рекомендований метод.
Під час генерації HTML-форми сервер створює унікальний, непередбачуваний та криптографічно стійкий токен. Він прив’язаний до користувача/сесії та перевіряється на стороні сервера. Після отримання запиту сервер перевіряє, чи відповідає токен тому, що зберігається для сесії користувача.
Кожен запит на форму або зміну стану (наприклад, POST, зміна налаштувань, переказ коштів) повинен містити анти-CSRF токен. Якщо його немає – запит слід заблокувати.
Це можна реалізувати за допомогою:
- Токенів зі збереженням стану (зберігаються на сервері)
- Токенів без збереження стану (підписаних токенів або на основі HMAC)
GET не повинен використовуватися для дій зі зміною стану.
2. Політика щодо файлів cookie SameSite та налаштування безпечних файлів cookie
Варто надсилати файли cookie сесії лише тоді, коли запит надходить з того самого сайту (SameSite=strict або lax).
Це значно ускладнює спроби CSRF, що надходять із зовнішніх вебсайтів.
Навіть якщо анти-CSRF токени не реалізовані, політика використання файлів cookie SameSite додає додатковий рівень безпеки, хоча це не є повним розв’язанням проблеми.
3. Перевірка HTTP-заголовків
Слід перевіряти заголовки Origin або Referer, щоб переконатися, що запит походить з очікуваного домену.
Сучасний захист також включає використання заголовків Fetch Metadata (Sec-Fetch-Site, Sec-Fetch-Mode тощо), що дозволяє серверу визначити, чи надходить запит з того самого сайту, чи із зовнішнього контексту.
4. Кастомні заголовки для запитів AJAX / API
Для кінцевих точок AJAX або API, які змінюють стан, програми можуть вимагати кастомні заголовки (наприклад, X-Requested-With або інші) та перевіряти їх на сервері.
Браузери не дозволяють зовнішнім сайтам надсилати кастомні заголовки без CORS (Cross-Origin Resource Sharing), тому це блокує більшість міжсайтових запитів.
Однак, якщо політика CORS занадто слабка, це може не спрацювати належним чином.
5. Використання фреймворків/бібліотек з вбудованим захистом CSRF
Більшість сучасних фреймворків включають захист CSRF “з коробки”. Варто використовувати їх, замість того, щоб створювати щось власне.
Якщо фреймворку бракує вбудованого захисту, можна додати бібліотеку або модуль.
Тестування вебсайтів на CSRF
Тестування безпеки є важливою частиною загальної стратегії, оскільки воно може точно дати вам знати, що вебсайт дійсно не вразливий до CSRF. Це можна зробити за допомогою статичного аналізу (SAST) та тестування методом чорної скриньки (DAST).
- SAST знаходить вразливості безпосередньо в коді, дозволяючи сканувати всю базу коду. Для цієї мети можна використовувати швидкий двигун Mend SAST.
- DAST безпечно імітує дії зловмисника на вебсайтах, щоб виявити вразливості, як це роблять хакери в реальних обставинах. Invicti (на основі Acunetix та Netsparker) також може підтверджувати результати, щоб підвищити точність та заощадити час.
Якщо ви хочете безкоштовно протестувати Invicti DAST або Mend SAST, залиште свої контактні дані нижче, і ми зв’яжемося з вами протягом робочого часу:
