# Cross-Site Request Forgery (CSRF)
### Что такое CSRF?
Cross-Site Request Forgery (CSRF) — это уязвимость веб-безопасности, позволяющая атакующему побудить пользователей выполнить действия, которые они не собирались выполнять. Она позволяет частично обойти политику единого источника (same origin policy), предназначенную для предотвращения вмешательства разных веб-сайтов друг в друга.
{% hint style="success" %}
**Лабораторные работы** Если вы уже знакомы с базовыми концепциями уязвимостей CSRF и просто хотите попрактиковаться в их эксплуатации на реалистичных, преднамеренно уязвимых целях, вы можете получить доступ ко всем лабораториям по ссылке ниже.
* [Посмотреть все лабораторные работы по CSRF](https://portswigger.net/web-security/all-labs#cross-site-request-forgery-csrf)
{% endhint %}
## Каковы последствия атаки CSRF?
В успешной атаке CSRF атакующий заставляет пользователя непреднамеренно выполнить действие. Например, это может быть изменение адреса электронной почты в аккаунте, смена пароля или перевод средств. В зависимости от характера действия атакующий может получить полный контроль над учётной записью пользователя. Если скомпрометированный пользователь имеет привилегированную роль в приложении, атакующий может получить полный контроль над всеми данными и функциональностью приложения.
## Как работает CSRF?
Чтобы атака CSRF была возможна, должны выполняться три ключевых условия:
* **Значимое действие**. В приложении есть действие, совершение которого выгодно инициировать атакующему. Это может быть привилегированное действие (например, изменение прав других пользователей) или любое действие с пользовательскими данными (например, изменение собственного пароля пользователя).
* **Обработка сессий на основе cookie.** Выполнение действия включает отправку одного или нескольких HTTP‑запросов, и приложение полагается исключительно на сессионные cookie для идентификации пользователя, сделавшего запросы. Нет других механизмов отслеживания сессий или проверки пользовательских запросов.
* **Отсутствие непредсказуемых параметров запроса**. Запросы, выполняющие действие, не содержат параметров со значениями, которые атакующий не может определить или угадать. Например, функция смены пароля не уязвима, если атакующему нужно знать значение текущего пароля.
Например, допустим, в приложении есть функция, позволяющая пользователю изменить адрес электронной почты в своём аккаунте. При выполнении этого действия пользователь отправляет запрос HTTP, подобный следующему:
```
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com
```
Это соответствует условиям, необходимым для CSRF:
* Действие смены адреса электронной почты в учётной записи пользователя представляет интерес для атакующего. После этого действия атакующий обычно может инициировать сброс пароля и получить полный контроль над учётной записью пользователя.
* Приложение использует сессионный cookie для идентификации пользователя, отправившего запрос. Нет других токенов или механизмов отслеживания пользовательских сессий.
* Атакующий может легко определить значения параметров запроса, необходимых для выполнения действия.
При выполнении этих условий атакующий может создать веб‑страницу, содержащую следующий HTML:
```html
```
Если жертва посетит веб-страницу атакующий, произойдёт следующее:
* Страница атакующий инициирует запрос HTTP к уязвимому сайту.
* Если пользователь вошёл на уязвимый сайт, его браузер автоматически добавит в запрос его сессионный cookie (при условии, что не используются [SameSite cookie](#rasprostranyonnye-mekhanizmy-zashity-ot-csrf))
* Уязвимый сайт обработает запрос обычным образом, посчитает его сделанным жертвой и изменит её адрес электронной почты.
{% hint style="info" %}
**Note**
Хотя CSRF обычно описывают в контексте управления сессиями на основе cookie, она также возникает в других случаях, когда приложение автоматически добавляет к запросам некоторые пользовательские учётные данные, например при HTTP Basic аутентификации и аутентификации на основе сертификатов.
{% endhint %}
## Как сконструировать атаку CSRF
Ручное создание HTML, необходимого для CSRF-эксплойта, может быть утомительным, особенно когда требуемый запрос содержит много параметров или в нём есть другие особенности. Самый простой способ сконструировать CSRF-эксплойт — использовать [CSRF PoC generator](https://portswigger.net/burp/documentation/desktop/tools/engagement-tools/generate-csrf-poc), встроенный в Burp Suite Professional:
* Выберите любой запрос в Burp Suite Professional, который вы хотите протестировать или проэксплуатировать.
* В контекстном меню (правый клик) выберите Engagement tools / Generate CSRF PoC.
* Burp Suite сгенерирует HTML, который спровоцирует выбранный запрос (без cookie, они будут добавлены автоматически браузером жертвы).
* В генераторе CSRF PoC вы можете настроить различные параметры, чтобы точно подогнать атаку. В некоторых необычных ситуациях это может понадобиться для обработки специфичных особенностей запросов.
* Скопируйте сгенерированный HTML в веб-страницу, откройте её в браузере, вошедшем на уязвимый сайт, и проверьте, что нужный запрос успешно отправляется и выполняется желаемое действие.
{% hint style="success" %}
**LAB**
[**CSRF vulnerability with no defenses**](https://portswigger.net/web-security/csrf/lab-no-defenses)
{% endhint %}
## Как доставить CSRF-эксплойт
Механизмы доставки атак CSRF по сути такие же, как для Reflected XSS. Обычно атакующий размещает вредоносный HTML на контролируемом им сайте, а затем побуждает жертв посетить этот сайт. Это можно сделать, отправив пользователю ссылку на сайт по электронной почте или в сообщении в соцсетях. Или, если атака размещена на популярном сайте (например, в пользовательском комментарии), атакующий может просто ждать, пока пользователи посетят сайт.
Обратите внимание, что некоторые простые CSRF-эксплойты используют метод GET и могут быть полностью самодостаточными в виде одного URL (унифицированный указатель ресурса) на уязвимом сайте. В этой ситуации атакующему может не понадобиться внешний сайт, и он может напрямую отправить жертвам вредоносный URL на уязвимом домене. В приведённом выше примере, если запрос на смену адреса электронной почты можно выполнить методом GET, то самодостаточная атака будет выглядеть так:
```html
```
{% hint style="info" %}
**Подробнее**
> [XSS vs CSRF](https://wr3dmast3r.gitbook.io/portswiggerfundamental/client-side/csrf/xss-vs-csrf)
> {% endhint %}
## Распространённые механизмы защиты от CSRF
В наши дни успешный поиск и эксплуатация уязвимостей CSRF часто связаны с обходом мер противодействия, внедрённых целевым сайтом, браузером жертвы или обоими. Наиболее распространённые защиты, с которыми вы столкнётесь:
* **CSRF-токены** — CSRF-токен — это уникальное, секретное и непредсказуемое значение, которое генерируется серверным приложением и передаётся клиенту. При попытке выполнить чувствительное действие, например отправку формы, клиент должен включить корректный CSRF-токен в запрос. Это делает усложняет проведение эксплуатации для атакующего.
* **SameSite cookies** — SameSite — это механизм безопасности браузера, который определяет, когда cookie сайта включаются в запросы, исходящие с других сайтов. Поскольку запросы на выполнение чувствительных действий обычно требуют аутентифицированного сессионного cookie, соответствующие ограничения SameSite могут помешать атакующему инициировать такие действия Cross-Site. С 2021 года Chrome по умолчанию применяет ограничения SameSite со значением `Lax`. Поскольку это предлагаемый стандарт, мы ожидаем, что другие основные браузеры в будущем примут такое же поведение.
* **Проверка на основе Referer** — Некоторые приложения используют заголовок HTTP Referer, чтобы попытаться защититься от CSRF-атак, обычно проверяя, что запрос пришёл с домена самого приложения. В целом это менее эффективно, чем проверка CSRF-токена.
Более детальное описание каждой из этих защит, а также возможных способов их обхода, приведено в следующих материалах. Они включают интерактивные лабораторные работы, позволяющие отработать полученные знания на реалистичных, намеренно уязвимых целях.
{% hint style="info" %}
**Подробнее**
* [Обход проверки CSRF-токена](https://wr3dmast3r.gitbook.io/portswiggerfundamental/client-side/csrf/obkhod-proverki-csrf-tokena)
* [Обход ограничений SameSite для cookie](https://wr3dmast3r.gitbook.io/portswiggerfundamental/client-side/csrf/obkhod-ogranichenii-samesite-dlya-cookie)
* [Обход CSRF-защит на основе Referer](https://wr3dmast3r.gitbook.io/portswiggerfundamental/client-side/csrf/obkhod-csrf-zashit-na-osnove-referer)
{% endhint %}
Подробности о том, как правильно реализовать эти меры на ваших собственных сайтах, чтобы предотвратить некоторые из этих проблем, смотрите:
* [Как предотвращать уязвимости CSRF](https://wr3dmast3r.gitbook.io/portswiggerfundamental/client-side/csrf/kak-predotvrashat-uyazvimosti-csrf)