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

Материал из InformationSecurity WIKI
Перейти к: навигация, поиск
м (→‎Ссылки)
 
(не показано 6 промежуточных версий этого же участника)
Строка 1: Строка 1:
 +
[[Категория:Web]]
 
'''Уязвимость CSRF (XSRF)'''
 
'''Уязвимость CSRF (XSRF)'''
  
Строка 4: Строка 5:
  
  
−
=== Ссылки по теме ===
+
 
 +
= Найти уязвимую форму =
 +
 
 +
Суть 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-токена, то проверка токена может игнорироваться.
 +
 
 +
=== Предсказуемые токены ===
 +
 
 +
Если у вас есть возможность предсказывать токены, то это еще один вариант создания CSRF-формы. Например, CSRF токен оказался логином пользователя в base64.
 +
 
 +
== HTTP-методы запроса ==
 +
 
 +
=== Проверка формы с другими методами ===
 +
 
 +
В некоторых случаях можно попробовать, например, отправить вместо POST-запроса - GET.
 +
 
 +
 
 +
=== Нестандартный обход обозначения метода ===
 +
 
 +
Некоторые нестандартные обходы метода используя, например, параметр "_method" (можно попробовать как в GET-поле, так и в POST):
 +
<syntaxhighlight lang="bash" line="1" enclose="div" style="overflow-x:scroll" >
 +
https://example.com/my/dear/api/val/num?_method=PUT
 +
</syntaxhighlight>
 +
 
 +
Также методы могут быть указаны в заголовках:
 +
 
 +
* X-HTTP-Method
 +
 
 +
* X-HTTP-Method-Override
 +
 
 +
* X-Method-Override
 +
 
 +
 
 +
== Cookies ==
 +
 
 +
=== Headers injection ===
 +
 
 +
Если вам требуется выставить переменную Cookie у жертвы, то можно воспользоваться уязвимостью Headers injection (при ее наличии).
 +
 
 +
Пример CSRF-attack формы, которая выставляет у жертвы Cookie "csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E":
 +
<syntaxhighlight lang="html" line="1" enclose="div" style="overflow-x:scroll" >
 +
<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>
 +
</syntaxhighlight>
 +
 
 +
 
 +
 
 +
= Ссылки =
  
 
https://github.com/codedokode/pasta/blob/master/security/xsrf.md
 
https://github.com/codedokode/pasta/blob/master/security/xsrf.md
Строка 11: Строка 157:
  
 
habrahabr.ru/post/235247/ Типичные ошибки при защите сайтов от CSRF-атак
 
habrahabr.ru/post/235247/ Типичные ошибки при защите сайтов от CSRF-атак
 +
 +
[https://book.hacktricks.xyz/pentesting-web/csrf-cross-site-request-forgery/ hacktricks]
 +
 +
[https://portswigger.net/web-security/csrf PortSwigger]

Текущая версия на 11:08, 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-запроса
    • text/plain
    • text/xml


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

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

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


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

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


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

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


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

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

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

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

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

GET-форма

HTTP-форма

AJAX-форма

Обход защиты

CSRF-токены

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

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

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

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

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

Если у вас есть возможность предсказывать токены, то это еще один вариант создания CSRF-формы. Например, CSRF токен оказался логином пользователя в base64.

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

PortSwigger

Источник — «http://itsecwiki.org/index.php?title=Csrf&oldid=1125»