SSRF (Server-Side Request Forgery) при загрузке ресурса по пользовательскому URL возникает, когда сервер принимает ссылку от клиента и отправляет запрос к ней без должной проверки. Атакующий может подставить внутренний адрес (например, 127.0.0.1 или IP базы данных), чтобы получить доступ к закрытым сервисам, скачать файлы из внутренней сети или вызвать действия на стороне сервера. Защита строится на строгой валидации входящих параметров, изоляции сетевых зон и ограничении возможностей самого сервера.

Определение вектора атаки: как SSRF эксплуатируется при загрузке по URL

Уязвимость возникает в коде, который принимает строку от пользователя и передает её в HTTP-клиенте сервера. Если приложение не проверяет содержимое этой строки, оно может выполнить запрос к любому адресу в интернете или внутри сети.

Атакующий использует это для доступа к службам, которые должны быть закрыты (например, метаданные облачного провайдера на 169.254.169.254, внутренние API базы данных или админ-панели).

Пример условной уязвимости: функция fetchImage(url), где url берется из формы заявки. Если пользователь вводит http://127.0.0.1/admin, сервер отправит запрос к этому адресу и вернет содержимое страницы.

Механизм защиты: валидация и санитизация входящих параметров

Первый шаг — проверка протокола. Разрешите только http и https. Запретите ftp, file, gopher и другие схемы, которые могут привести к нежелательным действиям.

Второй шаг — разрешение DNS. После того как браузер или клиент сервера разберет доменное имя в IP-адрес, нужно проверить этот IP. Если он попадает в диапазон приватных сетей (10.x.x.x, 172.16-31.x.x, 192.168.x.x) или является loopback (127.x.x.x), запрос должен быть отклонен.

Третий шаг — защита от перенаправления. Атакующий может передать http://example.com?url=http://internal-ip. Нужно запретить редиректы и проверять конечный адрес после всех перенаправлений.

Изоляция сетевых зон: разделение внутренних и внешних ресурсов

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

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

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

Настройка таймаутов и лимитов на глубину перенаправления

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

Запретите глубокие редиректы. Установите лимит на количество перенаправлений (например, максимум 3). Это предотвращает цепочки перенаправлений, которые могут привести к доступу к внутренним ресурсам.

Блокировка опасных протоколов и схем перенаправления

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

Запретите использование URL-параметров для указания целевого адреса. Используйте только доверенные источники данных.

Проверка доступности целевых ресурсов (DNS, IP)

Перед отправкой запроса проверьте, что целевой адрес существует и доступен из внешней сети. Используйте DNS-сервер, который не разрешает внутренние адреса.

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

Мониторинг аномальных паттернов запросов

Ведите логи всех запросов к внешним ресурсам. Ищите подозрительные шаблоны, например, частые запросы к внутренним IP-адресам или необычные User-Agent.

Настройте алерты на события, которые могут указывать на попытку эксплуатации уязвимости.

Тестирование уязвимостей: методы проверки эффективности защиты

Регулярно проводите тесты на проникновение, чтобы убедиться, что защита работает. Используйте инструменты для автоматизированного поиска SSRF.

Проверяйте, что после внедрения изменений уязвимость не возвращается.

Вопросы и ответы

Можно ли полностью исключить риск SSRF?

Полностью исключить риск невозможно, но можно свести его к минимуму с помощью строгой валидации и изоляции сетей.

Как часто нужно проверять защиту от SSRF?

Проверку следует проводить после каждого обновления кода или изменения конфигурации сети.

По теме

Похожие статьи