Уязвимость 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-запроса
- text/plain
- text/xml

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

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

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-форма

Обход защиты

CSRF-токены

Токен не прикреплен к сессии

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

Отсутствие токена -> Отсутствие проверки

В некоторых случаях, если не указана переменная CSRF-токена, то проверка токена может игнорироваться.

HTTP-методы запроса

Проверка формы с другими методами

В некоторых случаях можно попробовать, например, отправить вместо POST-запроса - GET.

Нестандартный обход обозначения метода

Некоторые нестандартные обходы метода используя, например, параметр "_method" (можно попробовать как в GET-поле, так и в POST):

https://example.com/my/dear/api/val/num?_method=PUT

Также методы могут быть указаны в заголовках:

X-HTTP-Method

X-HTTP-Method-Override

X-Method-Override

Cookies

Headers injection

Если вам требуется выставить переменную Cookie у жертвы, то можно воспользоваться уязвимостью Headers injection (при ее наличии).

Пример CSRF-attack формы, которая выставляет у жертвы Cookie "csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E":

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
      <input type="hidden" name="csrf" value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
      <input type="submit" value="Submit request" />
    </form>
    <img src="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
  </body>
</html>

Ссылки

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

https://learn.javascript.ru/csrf

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

hacktricks

Csrf