Этот пост я решил написать потому, что эти две уязвимости отличаются в названии всего одной буквой, но на практике это кардинально разные уязвимости, направленные на совершенно разные объекты.

━━━━━━━━━━━ Кто есть кто? ━━━━━━━━━━━

• CSRF (Cross-Site Request Forgery) это подделка запроса от имени пользователя. Уже авторизованный пользователь отправляет запрос на сайт, а сервер думает: «Раз запрос пришёл от пользователя, значит, он и инициировал его». Но на деле запрос был сформирован атакующим: от социальной инженерии до использования iframe, если на сайте отсутствует CSP. ⇨ Ранее я уже разбирал CSP в статье: «Какова необходимость в CSP (Content Security Policy)

• SSRF (Server-Side Request Forgery) это подделка запроса на стороне сервера. Злоумышленник заставляет уже сам сервер сходить по тому URL, который ему укажут. В результате сервер становится инструментом атаки на внутреннюю инфраструктуру.

━━━━━━━━━━━━━━━━━━━━━━━━ Разбор эксплуатации: CSRF ━━━━━━━━━━━━━━━━━━━━━━━━

1. CSRF-токен полностью отсутствует, и в запросе нет никаких непредсказуемых параметров. При этом приложение использует cookie-based session handling или другой механизм, где браузер сам автоматически добавляет учётные данные к запросу

2. GET-based CSRF. Некорректная реализация позволяет изменять данные через GET, хотя по нормальной логике и REST-практике для этого должны использоваться POST / PUT / PATCH / DELETE. В итоге защита может быть настроена только на “ожидаемые” методы, а GET остаётся слабым местом.

3. Токен проверяется только в том случае, если он присутствует. То есть отсутствие токена само по себе не приводит к отклонению запроса.

4. Токен не привязан к сессии пользователя. Например, сервер хранит пул токенов и проверяет лишь сам факт “валидности” токена, но не связывает его с конкретной пользовательской сессией.

5. Double Submit без нормальной серверной модели. Если приложение просто дублирует один и тот же CSRF-токен в cookie и в параметр запроса, а затем лишь сравнивает их между собой, такую реализацию можно считать слабой.

6. И множество других вариантов эксплуатации. Если есть возможность изучить реальную бизнес-логику и реализацию механизма защиты, нередко находятся нестандартные сценарии обхода. Очень часто такие уязвимости появляются не из-за “магии атакующего”, а из-за того, что разработчик не до конца понимает, что именно реализует.

━━━━━━━━━━━━━━━━━━━━━━ Разбор эксплуатации: SSRF ━━━━━━━━━━━━━━━━━━━━━━

1. Полное доверие на стороне сервера к пользовательским URL. Например, когда серверу можно передать адрес для подгрузки изображения / медиа / файла / превью, и он без ограничений делает запрос по этому адресу

2. Использование blacklist-подхода. Если мы строим защиту по принципу «вот сюда обращаться нельзя», её почти всегда можно обойти. Один из примеров — DNS Rebinding: сначала сервер проверяет домен атакующего и получает внешний IP-адрес, а затем при реальном запросе этот же домен уже резолвится во внутренний адрес, например 127.0.0.1.

3. Referer header как источник URL. Некоторые серверные analytics / preview / parser-механизмы читают URL из заголовка Referer, а затем сами переходят по нему.

4. Blind SSRF. Сервер делает запрос, но ответ не возвращается в клиентский response. В таком случае эксплуатация обычно строится через OAST-подходы.

━━━━━━━━━━━━━━━━ Защита: CSRF/SSRF ━━━━━━━━━━━━━━━━

1. CSRF-токены Уникальное секретное значение, которое сервер помещает в форму или запрос и затем проверяет при отправке и получении.

2. Проверка Referer / Origin Сервер должен проверять, с какого сайта пришёл запрос. Если источник не соответствует ожидаемому домену запрос отклоняется.

3. Корректная настройка CSP CSP не является прямой заменой CSRF-защиты, но позволяет уменьшить поверхность атаки и усложнить часть сценариев эксплуатации.

4. Белый список (Whitelist) Самый надёжный подход. Если приложению нужно обращаться только к api.example.com, это должно быть жёстко зафиксировано в логике приложения. Любой другой URL должен блокироваться.

5. Отключение неиспользуемых протоколов.

#IT #Web #Cybersecurity #Backend #CSRF #SSRF