Что такое SSRF-уязвимость, как ее находить и к чему она может привести?

Источник: https://github.com/AnaktaCTF/CTF/blob/main — WEB/SSRF.md

1. Введение в SSRF

SSRF (Server-Side Request Forgery) — это уязвимость веб-приложений, при которой злоумышленник может заставить сервер выполнять запросы к произвольным ресурсам, включая внутренние системы, доступ к которым извне обычно запрещен.

2. Как работает SSRF?

SSRF-атака происходит следующим образом:

Злоумышленник отправляет специально сформированный запрос к веб-приложению.
Сервер, доверяя этому запросу, выполняет его от своего имени.
Вредоносный запрос позволяет атакующему:
- Получить доступ к внутренним API и службам компании.
- Обходить механизмы аутентификации.
- Сканировать внутреннюю сеть организации.
- Извлекать конфиденциальную информацию, включая учетные данные.

Пример SSRF-атаки через загрузку изображений

Допустим, в веб-приложении есть функционал предварительного просмотра изображений, который загружает картинку по указанному URL:

import requests

def fetch_image(url):
    response = requests.get(url)
    return response.content

Атакующий может отправить запрос на http://localhost:8080/admin и получить данные, предназначенные только для администраторов.

Пример SSRF-атаки через облачные метаданные

В AWS и других облачных платформах метаданные сервера доступны по IP 169.254.169.254. Если приложение позволяет делать запросы к произвольным URL, можно попробовать извлечь учетные данные:

curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/"

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

3. Как находить SSRF-уязвимости?

3.1. Анализ входных данных

Необходимо проверять, принимает ли сервер внешние URL-адреса в параметрах запроса (например, ?url=http://example.com). Если приложение выполняет запрос к переданному адресу, оно потенциально уязвимо.

3.2. Использование Burp Suite

Burp Suite позволяет изменять передаваемые параметры и проверять, может ли сервер отправлять запросы на локальные или внутренние адреса, такие как:

http://localhost
http://127.0.0.1
http://169.254.169.254 (метаданные облачных серверов)
http://internal-service

3.3. Тестирование различных протоколов

Некоторые серверы поддерживают не только HTTP, но и другие протоколы:

file:// — доступ к локальной файловой системе.
gopher:// — старый протокол, позволяющий обойти ограничения и сформировать произвольный HTTP-запрос.
dict:// — потенциально может использоваться для туннелирования данных.

4. Последствия SSRF-атак

SSRF может привести к серьезным последствиям:

Доступ к внутренним системам — злоумышленник может взаимодействовать с сервисами, доступ к которым возможен только из внутренней сети.
Кража конфиденциальных данных — возможность запросов к метаданным облачных серверов (например, AWS, GCP, Azure) может привести к компрометации учетных данных.
Обход аутентификации — если внутренняя инфраструктура предполагает доверие к локальным запросам, атакующий может получить несанкционированный доступ.
Использование сервера для атак на другие системы — сервер можно использовать в качестве прокси для атак на сторонние ресурсы.

5. Как защититься от SSRF?

5.1. Ограничение списка разрешенных адресов (Allowlist)

Сервер должен разрешать запросы только к доверенным доменам и блокировать доступ к IP-адресам локальной сети.

5.2. Проверка и фильтрация входных данных

Принимаемые URL-адреса должны проходить строгую валидацию, исключая доступ к локальным адресам (127.0.0.1, localhost, 169.254.169.254 и т. д.).

5.3. Использование прокси-сервера

Перенаправление всех исходящих запросов через контролируемый прокси-сервер позволит блокировать вредоносные запросы.

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

Разрешать только HTTP и HTTPS, исключая возможность использования file://, gopher:// и других нестандартных протоколов.

6. Обход защиты от SSRF

Некоторые обходные техники, используемые злоумышленниками:

Обход фильтров через альтернативные представления IP-адресов (например, 2130706433 вместо 127.0.0.1).
Использование поддоменов (если фильтр блокирует IP, но позволяет доменные имена, можно использовать internal.example.com).
DNS Rebinding — злоумышленник регистрирует домен, который разрешается во внешний IP, а затем перенаправляет его на внутренний адрес.
Использование Open Redirect — если в системе есть редиректы, можно перенаправить запрос на внутренний ресурс.

Пример обхода через DNS Rebinding

<script>
    var img = new Image();
    img.src = "http://malicious.example.com/rebind?target=169.254.169.254";
</script>

Этот код может обойти защиту и получить доступ к закрытым ресурсам.

Пример обхода через редирект

Если приложение выполняет редиректы без проверки целевого URL, можно использовать такую атаку:

http://vulnerable-site.com/fetch?url=http://redirect.com/?url=http://internal-server

Если redirect.com перенаправляет на internal-server, можно заставить сервер сделать внутренний запрос.

7. Заключение

SSRF — опасная уязвимость, позволяющая атакующим использовать сервер в качестве посредника для доступа к внутренним ресурсам. Чтобы защититься от подобных атак, необходимо ограничивать список разрешенных адресов, проверять входные данные и использовать прокси-серверы для контроля исходящих запросов. Регулярное тестирование безопасности поможет выявить и устранить потенциальные уязвимости.

8. Где можно потренироваться?

Вы можете попрактиковаться в нахождении и эксплуатации SSRF-уязвимостей на платформе PortSwigger Web Security Academy, где представлены различные сценарии атак и защиты.(https://portswigger.net/web-security/ssrf#what-is-ssrf)

9. Полезные источники

Хабр "Атака с большим будущим: за что SSRF поместили в ТОП-10 киберугроз": https://habr.com/ru/companies/solarsecurity/articles/590673/

SQR "SSRF (подделка запроса на стороне сервера)": https://cqr.company/ru/web-vulnerabilities/ssrf/

Хабр "Где и как искать этот ваш SSRF: первые шаги в багхантинге": https://habr.com/ru/companies/pt/articles/842598/