Csrf — различия между версиями

Материал из InformationSecurity WIKI
Перейти к: навигация, поиск
м
м
Строка 4: Строка 4:
 
Эта уязвимость (XSRF, CSRF, Cross-Site Request Forge - межсайтовая подделка запросов) позволяет злоумышленнику, заманив пользователя на свою страницу, отправлять запросы от его имени. Чтобы понять то, что ниже написано, тебе надо знать, как делаются HTML-формы и как они обрабатываются на стороне PHP (что такое $_POST и $_GET).
 
Эта уязвимость (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://github.com/codedokode/pasta/blob/master/security/xsrf.md
Строка 12: Строка 92:
  
 
habrahabr.ru/post/235247/ Типичные ошибки при защите сайтов от CSRF-атак
 
habrahabr.ru/post/235247/ Типичные ошибки при защите сайтов от CSRF-атак
 +
 +
[https://book.hacktricks.xyz/pentesting-web/csrf-cross-site-request-forgery/ hacktricks]

Версия 10: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-заголовкам (или есть возможность их обойти)
  • Нет дополнительных заголовков, которые нельзя добавить в запрос.


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

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

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