Авторка: Катерина Іваненко, Invicti Brand Manager
Коротко про CSRF
CSRF, або підробка міжсайтового запиту – це тип вебатаки, яка обманом змушує браузер автентифікованого користувача виконати небажану дію на надійному сайті.
Вона використовує автентифіковану сесію користувача, змушуючи браузер надсилати шкідливий запит на вебсайт, на якому юзер вже увійшов у систему. Це може призвести до несанкціонованих дій, таких як зміна налаштувань облікового запису або переказ коштів без згоди користувача.
Ви можете дізнатися більше про вразливість та її типи з цієї статті.
Також на цій сторінці пояснюється різниця між CSRF та XSS (міжсайтовий скриптинг).
Основні причини CSRF
1) Покладання виключно на cookie для ідентифікації користувача
Якщо вебпрограма авторизує дії лише на основі cookie сесії, може бути виконаний будь-який міжсайтовий запит, який браузер робить з цими файлами. Браузери автоматично додають такі cookie, незалежно від сторінки, яка ініціювала запит, що є основною передумовою для CSRF.
2) Відсутні або неефективні анти-CSRF токени
Найнадійнішим захистом є токен для кожного запиту, який сайт зловмисника не може прочитати або вгадати. Якщо вони відсутні, передбачувані, повторно використовуються або не прив’язані до користувача/сеансу, CSRF стає можливим. OWASP чітко рекомендує захист на основі токенів як основну практику.
3) Небезпечне використання HTTP-методів
Якщо чутливі дії дозволені через GET (або якщо сервер не розрізняє читання (read) і запис (write)) зловмисники можуть ініціювати їх за допомогою <img>, <link> або простої навігації. Дії зі зміною стану через GET мають бути заборонені.
4) Слабка перевірка джерела запиту
Якщо вебсайт не перевіряє, звідки надходять запити (використовуючи заголовки Origin або Referer), він не може визначити, чи дія користувача була виконана на його власному сайті.
Зловмисники можуть обманом змусити браузер надсилати неавторизовані запити. Правильна перевірка заголовка Origin та дотримання суворого списку дозволених джерел допомагає запобігти цьому.
5) Неправильно налаштовані файли cookie SameSite
SameSite є хорошою практикою, але не панацеєю. Вебпрограми, які покладаються виключно на це, залишаються вразливими.
6) Неправильні конфігурації CORS (Cross-Origin Resource Sharing)
Якщо вебзастосунок дозволяє браузерам надсилати файли cookie або токени для входу (Access-Control-Allow-Credentials: true) та водночас приймає запити від будь-якого сайту, то вебсайт хакера може надсилати їх від імені користувача та, можливо, навіть бачити відповіді. Тобто дозвіл на всі джерела з довірою до облікових даних відкриває шлях до CSRF.
7) Потоки OAuth/OIDC без належного параметра стану
Потоки входу є окремим нюансом в CSRF: якщо клієнтська програма не прив’язує відповідь авторизації до сесії браузера, використовуючи криптографічно стійке значення стану (і не перевіряє його після повернення), зловмисники можуть вводити код або токени авторизації. Специфікації OAuth та основні постачальники ідентифікаційних даних визначають стан як обов’язковий елемент контролю CSRF.
8) Занадто тривалі сесії та зайві привілеї
Коли сесії ніколи не закінчуються, або включають надмірні привілеї, CSRF має більший вплив. Хоча це не є прямою причиною, вони можуть посилювати дану атаку.
Короткий cheat sheet для зниження ризику та пом’якшення CSRF
- Використання анти-CSRF токенів для запитів зі зміною стану та прив’язання до користувача/сесії. Ви можете знайти більше інформації про використання анти-CSRF токенів у цій статті.
- Налаштування GET лише для читання; забезпечення перевірки методів на стороні сервера.
- Перевірка, звідки надходить запит: використання заголовка Origin, а якщо він відсутній, покладання лише на ретельно перевірений хедер Referer.
- Налаштування файлів cookie: поєднання SameSite з токенами та використання прапорців Secure та HttpOnly, де це можливо.
- Посилення CORS: не варто використовувати Access-Control-Allow-Credentials: true, якщо це не дійсно потрібно, і ніколи не слід застосовувати його з * або скопійованим значенням Origin.
- Для OAuth/OIDC: генерація криптографічно стійкого стану, його прив’язка до сеансу користувача та перевірка під час редіректу.
- Конфігурації сесії: коротший термін, обмежені привілеї та додаткова авторизація для особливо чутливих операцій.
Як виявити вразливість CSRF у вебдодатках
Єдиний спосіб виявити CSRF – це тестування безпеки вебсайту. Для цієї мети можна використовувати різні сканери, наприклад:
- DAST (black-box): імітація дій хакера, що виявляє вразливості під час виконання вебпрограми.
- SAST (white-box): пошук дефектів безпосередньо в коді, подібно до помилок у тексті.
Найкраща практика – поєднувати обидва методи, оскільки динамічне тестування допомагає виявляти вразливості, специфічні для виконання вебзастосунку, але не може сканувати всю базу коду, як статичний аналіз. Обидва методи можна імплементувати в CI/CD, при цьому SAST інтегрується на ранніх етапах.
Якщо ви хочете безкоштовно протестувати такі рішення, це може бути DAST від Invicti (на основі Acunetix та Netsparker) або продукт, що включає SAST, SCA, безпека контейнерів, такий як Mend.io. Для цього, будь ласка, залиште свої контактні дані нижче:
Запит на безкоштовне тестування Invicti/Mend.io
Залиште контакти і ми з вами зв’яжемось
