Кейс: CSRF в платёжной/финтех платформе (аналогичный PayPal‑репорту)

Суть: endpoint для добавления альтернативного e‑mail/адреса доставки или метода восстановления принимал POST‑запрос без проверки CSRF‑токена. Это позволяло атакующему через скрытый запрос привязать контролируемый e‑mail к аккаунту жертвы.

Как это выглядело (упрощённый пример):

<form action="https://example.payments.com/account/add_email" method="POST">
  <input type="hidden" name="email" value="attacker@evil.example"/>
</form>
<script>document.forms[0].submit();</script>

Последствия: привязка чужого e‑mail давала возможность инициировать сброс пароля или перехватить уведомления от сервиса, облегчая дальнейшее взлом аккаунта.

Рекомендация: требовать уникальный CSRF‑token для этого действия, подтверждение по уже зарегистрированному e‑mail, лимит на смену и оповещения владельца аккаунта.

Кейс: CSRF, влияющий на управление устройствами в аккаунте (аналогичный кейсу Google)

Суть: действие удаления доверённого устройства или отзыва сессии выполнялось через POST без надёжной проверки Origin/Referer и без CSRF‑токена, поэтому достаточно было отправить сформированный POST‑запрос от имени логинящегося пользователя.

Иллюстрация атаки:

<form action="https://accounts.example.com/device/remove" method="POST">
  <input type="hidden" name="device_id" value="4567"/>
</form>
<script>document.forms[0].submit();</script>

Почему опасно: удаление устройств могло вызвать принудительный выход пользователя и заметно упростить последующую фишинговую атаку или попытки захвата аккаунта.

Рекомендации: на такие критичные операции требовать повторную аутентификацию (reauth), проверять заголовок Origin/Referer, использовать SameSite для cookie и внедрять CSRF‑токены.

Кейс: CSRF в социальной платформе (аналогичный Meta/Facebook)

Суть: endpoint публикации контента или отправки сообщений принимал контент из POST‑формы без подтверждения отправителя. Это позволяло публиковать посты от имени залогиненного пользователя при открытии специально подготовленной страницы.

Пример встраиваемого payload‑а:

<form action="https://social.example.com/post/create" method="POST">
  <input name="message" value="You have been pwned"/>
</form>
<script>document.forms[0].submit();</script>

Последствия: публикация фишинговых ссылок от доверенных аккаунтов, репутационные потери и массовое распространение вредоносных ссылок.

Ремедиация: внедрить CSRF‑защиту, проверять Origin/Referer и применять Content Security Policy (CSP) в дополнение к проверкам на сервере.

Кейс: SSRF и облачные метаданные (типовой пример, часто встречается в публичных отчётах)

Суть: приложение позволяло пользователю указать URL для предпросмотра/фетчинга изображения или проверки URL. Сервер обращался к любому URL без проверки, поэтому атакующий указал адрес внутреннего metadata‑endpoint (например, http://169.254.169.254/ для AWS/GCP), и получил чувствительные данные — токены IAM/ролей.

Почему это критично:

• Доступ к метаданным облака позволяет получить временные креденшиалы и выполнить дальнейшие атаки на инфраструктуру;
• SSRF может служить стартом для lateral movement по внутренней сети организации;
• SSRF в публичных багбаунти‑отчётах неоднократно приводил к полному компромату инфраструктуры.

Защита: whitelist только разрешённых хостов и схем, блокировка private‑диапазонов и localhost, DNS‑pinning (проверка IP после резолва), отказ от прямого fetch по URL от клиента, использование прокси с ограничениями.

Кейс: SSRF, отражённый на внутренние HTTP‑сервисы (аналогичные публичным инцидентам в крупных платформах)

Суть: endpoint, выполняющий серверный фетч стороннего контента (например, og‑мета, превью ссылок), позволял получить доступ к внутренним сервисам — административным интерфейсам, внутренним API, мониторинговым панелям.

Пример:

GET /fetch?url=http://internal-db:8080/health

Если сервер может резолвить внутренние DNS‑имена, запросы приведут к раскрытию статуса и конфиденциальных данных.

Рекомендации: валидировать входные URL, применять allowlist, блокировать не‑HTTP схемы (file://, gopher:// и т.п.), контролировать перенаправления и таймауты.

Кейс: SSRF через обработку пользовательских Webhooks/Callbacks

Суть: сервис позволял пользователям регистрировать callback/endpoint, который сервис вызывал (webhook). Отсутствие проверки допустимых хостов привело к тому, что злоумышленник зарегистрировал URL, указывающий на внутреннюю службу, и сервис аккумулировал чувствительные данные.

Защита: подтверждение доверенных webhook‑endpoint’ов (через проверочные токены), ограничение списка доменов, и проверка содержимого ответов.