Версия 06:05, 26 марта 2022

Уязвимость CSRF (XSRF)

Эта уязвимость (XSRF, CSRF, Cross-Site Request Forge - межсайтовая подделка запросов) позволяет злоумышленнику, заманив пользователя на свою страницу, отправлять запросы от его имени. Чтобы понять то, что ниже написано, тебе надо знать, как делаются HTML-формы и как они обрабатываются на стороне PHP (что такое $_POST и $_GET).

Стандартная эксплуатация

Найти уязвимую форму

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

Требования

Параметры авторизации

Авторизация (при ее наличии) использует параметр(ы) из следующего списка, иначе скорее всего не получится эксплуатировать:

• Айпи-адрес жертвы - тк запрос будет выполняться с айпи жертвы

• Cookies
  • При AJAX-форме сторит учитывать, что у куки могут быть 3 состояния:
    • Strict - нельзя отправить через AJAX
    • Lax - можно отправить только в GET-запросе
    • None - можно отправить в любом запросе.

• HTTP Basic Auth

• HTTP Digest Auth - не проверял, но тоже должно работать.

Тип формы

Действие формы должно влиять на безопасность. Например, форма по переключению из темной темы в светлую, хоть и наносит критический урон клиенту, но никак не влияет на безопасность системы.

Как правило, используются два типа формы:

• GET-формы - просто стандартный переход по URL, не особо интересно тк эксплуатируется просто отпрвкой нужной ссылки жертве

• POST-формы - когда значения параметров формы отправляются в конце HTTP-запроса:
  • multipart/form-data - чаще всего используется вместе с отправкой файлов тк экономит место (не кодирует в URLencode)
  • application/x-www-form-urlencoded - параметры будут кодироваться используя URLencode (a=1&b=2&c=%20).
  • application/json - JSON в конце HTTP-запроса
  • application/xml - XML в конце HTTP-запроса

Предсказуемые параметры

Не должно быть непредсказуемых параметров, которые будут проверяться при парсинге параметров запроса.

• CSRF-токены - специальные поля, призванные защитить от данной атаки, чаще всего прикреплены к сессии пользователя.

• CAPTCHA

• Пароль пользователя

Время жизни параметров

В некоторых случаях требуется заранее подготовить параметры, которые со временем могут меняться. Например, вы в личном кабинете генерируете идентификатор перевода валюты, добавляете его в форму и ждете, пока жертва отправит эту форму. Но идентификатор может "протухнуть" например через пару часов и это нужно учитывать.

Возможность выполнять запросы со сторонних ресурсов

• Отсутствие фильтров по Referer или Origin HTTP-заголовкам (или есть возможность их обойти)

• Нет дополнительных заголовков, которые нельзя добавить в запрос.

• Некорректно настроенный CORS ( Cross-Origin Resource Sharing ) - https://developer.mozilla.org/ru/docs/Web/HTTP/CORS

Эксплуатация

Эксплуатация может быть тремя способами:

1. В случае с GET-формой - отправка ссылки для перехода, чаще всего не используя сторонние сетевые ресурсы.

2. Используя автозаполняюмую HTTP-форму

3. Используя AJAX с запросом на сторонний сетевой ресурс.

GET-форма

HTTP-форма

AJAX-форма

Ссылки

https://github.com/codedokode/pasta/blob/master/security/xsrf.md

https://learn.javascript.ru/csrf

habrahabr.ru/post/235247/ Типичные ошибки при защите сайтов от CSRF-атак

hacktricks