Сервис загружает ресурс по URL, переданному пользователем. Какую угрозу нужно моделировать на границе исходящих запросов?
Нужно моделировать SSRF — подделку серверного запроса. Пользователь может заставить сервис обратиться не только к внешнему ресурсу, но и к внутренним адресам, служебным интерфейсам или метаданным облачной среды.
Защита должна включать проверку назначения, контроль разрешённых схем и адресов, запрет доступа к внутренним диапазонам и сетевое ограничение исходящего трафика. Одной проверки URL на стороне приложения недостаточно.
Веб-сервисы часто получают URL для загрузки изображений, импорта данных, проверки ссылок или генерации превью. Исходно такой запрос выглядел как обычная функция доступа к внешнему ресурсу, но сервер при этом обладает сетевыми возможностями, которых нет у пользователя.
Это сформировало отдельную модель угроз: внешний ввод влияет на действие доверенного компонента внутри защищённой сети. Поэтому границу безопасности стали рассматривать не только на входе в приложение, но и между приложением и сетью, куда оно может отправлять запросы.
Если сервис без ограничений загружает указанный URL, атакующий может передать адрес локального интерфейса, внутреннего сервиса или служебного endpoint. Ответ может раскрыть конфигурацию, токены, диагностические данные или сведения о внутренней топологии.
Опасность определяется не только чтением ответа. Если исходящий запрос допускает изменение состояния, сервис может выполнить внутреннюю административную операцию от имени самого сервера. Дополнительный риск возникает при перенаправлениях, альтернативных представлениях IP-адресов и различиях между тем, как адрес проверяет приложение и как его разрешает сетевой стек.
Сначала нужно определить допустимое назначение: например, разрешать только HTTPS и заранее известные домены либо использовать отдельный шлюз загрузки с ограниченным набором разрешённых направлений. Проверять следует не только текст URL, но и фактически разрешённый адрес после разбора имени, включая IPv4, IPv6, локальные и зарезервированные диапазоны.
Нужно контролировать цепочку перенаправлений: каждый новый адрес должен проходить те же проверки, а безопаснее вообще запрещать перенаправления, если они не нужны функционально. Следует ограничить порты, размер ответа, время ожидания, количество переходов и типы ресурсов.
Надёжная архитектура использует сетевую изоляцию. Компонент, выполняющий загрузку, размещают в отдельном сегменте без доступа к административным интерфейсам, облачным метаданным и внутренним базам данных; исходящий трафик разрешают по принципу минимальных привилегий.
DNS-проверка сама по себе не является достаточной защитой. Адрес может измениться после проверки, а разные сетевые компоненты могут по-разному обрабатывать имя. Поэтому важны согласованная резолюция, повторная проверка результата и сетевые правила, ограничивающие фактическое соединение.
Логирование и мониторинг помогают обнаруживать злоупотребления, но не заменяют предотвращение. Полный запрет исходящих запросов повышает безопасность, однако может нарушить бизнес-функцию; allowlist обычно безопаснее denylist, но требует сопровождения при изменении внешних интеграций.
Сервис предварительного просмотра документов принимал URL и скачивал файл для конвертации. Первоначальный вариант разрешал все HTTP-запросы, а затем проверял только MIME-тип ответа. Такой контроль не защищал от обращения к внутренним адресам и позволял атакующему использовать сервис как сетевой прокси.
Рассматривались три варианта. Полный запрет загрузки устранял угрозу, но делал функцию бесполезной. Проверка URL по чёрному списку была проще, однако оставалась хрупкой из-за новых диапазонов, перенаправлений и нестандартных форм записи адресов. Размещение загрузчика в изолированном сегменте с allowlist доменов, запретом доступа к приватным сетям, ограничением портов и отключением перенаправлений требовало больше инфраструктурной работы, но сохраняло функцию при существенно меньшем риске.
Выбрали третий вариант и дополнительно ограничили размер ответа, время выполнения и права процесса конвертации. В результате даже ошибка в прикладной проверке не давала загрузчику сетевой доступ к критичным внутренним ресурсам, а попытки обращения к запрещённым направлениям фиксировались мониторингом.
1. Достаточно ли запретить URL, содержащие локальный адрес?
Нет. Локальный или внутренний адрес может быть представлен в другом формате, получен через DNS или достигнут после перенаправления. Проверять нужно итоговое сетевое назначение на каждом этапе, а дополнительной защитой должны быть сетевые правила, не зависящие от корректности прикладного валидатора.
2. Чем SSRF отличается от обычного доступа пользователя к внутреннему ресурсу?
При обычном доступе запрос идёт из пользовательского окружения и ограничен его сетевыми правами. При SSRF запрос выполняет сервер, который может находиться внутри доверенной сети и иметь доступ к служебным адресам или учётным данным. Поэтому атакующий получает сетевое положение и полномочия сервера, хотя сам к внутренней сети доступа не имеет.
3. Защищает ли SSRF-фильтр от изменения состояния внутреннего сервиса?
Не обязательно. Фильтр может ограничить адреса, но разрешённый внутренний endpoint всё ещё способен принять опасный метод или параметры. Для снижения риска нужны запрет небезопасных методов, минимальные сетевые и прикладные права загрузчика, изоляция административных интерфейсов и защита от подстановки серверных учётных данных в исходящие запросы.