РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-30
URL в инструменте AI-агента: как защитить сервер от SSRF
Как не дать аргументу функции превратить загрузку страницы в доступ к внутренним ресурсам сервера.
Если инструмент агента загружает переданный URL на сервере, проверка имени функции и JSON аргументов ещё не защищает от SSRF. Приложение должно определить разрешённые назначения, проверить адрес после разбора и контролировать фактическое соединение. Перенаправление и изменение DNS могут изменить конечную точку. Инструкции в промпте полезны для поведения модели, но сетевую границу реализуют код и инфраструктура. Проверяйте защиту на изолированном стенде с собственными адресами и синтетическими ответами.
1. Опишите разрешённую операцию
Определите, действительно ли агенту нужен произвольный интернет. Для интеграции с известным сервисом безопаснее фиксированный серверный клиент и ограниченный набор операций. Не передавайте модели полномочия выбирать схему, порт и произвольные заголовки, если задача этого не требует. Отдельно задайте политику доступа к внутренним ресурсам. Разрешение пользователя прочитать публичную страницу не означает разрешения обращаться к локальной сети или служебным адресам окружения.
2. Проверяйте разобранный адрес и DNS
Используйте стандартный парсер URL и разрешайте только необходимые схемы. Сравнение строк по наличию доверенного слова не проверяет реальное имя хоста. Для сетевого назначения учитывайте все разрешённые адреса, включая IPv6 и специальные диапазоны. OWASP рассматривает allowlist и защиту сетевого уровня как взаимодополняющие меры. Важно, чтобы проверенный адрес совпадал с адресом фактического подключения: независимая предварительная проверка не должна создавать ложную уверенность при последующем новом разрешении DNS.
3. Контролируйте редиректы и размер ответа
Не следуйте перенаправлению автоматически без применения той же политики к новому назначению. Ограничьте число переходов, время соединения, общий срок операции и объём прочитанного ответа. Не пересылайте авторизационные заголовки на другой хост. Проверка конечного текста уже после загрузки не предотвращает нежелательный сетевой запрос. Для файлов дополнительно проверяйте фактический формат и допустимый размер после декодирования, а не только обещанное значение заголовка ответа.
4. Проверьте отказ и журнал действий
Поднимите собственный тестовый сервер с разрешёнными и запрещёнными маршрутами, редиректами и медленным ответом. Не обращайтесь к чужим внутренним адресам ради демонстрации. Убедитесь, что отказ происходит до соединения и не приводит к повтору через менее защищённый инструмент. В журнале храните причину отказа без секретных заголовков. Модель должна получить понятную ошибку политики, чтобы завершить задачу или предложить пользователю загрузить документ другим разрешённым способом.
Частые вопросы
Достаточно ли запретить локальные адреса в промпте?
Нет. Промпт не управляет сетевым соединением. Запрет должен действовать в реализации инструмента и его окружении.
Можно ли разрешить все HTTPS-ссылки?
HTTPS шифрует транспорт, но не подтверждает допустимость назначения. Политика хоста, порта и конечного IP всё равно нужна.
Почему важны перенаправления?
Первый адрес может быть разрешённым, а следующий вести в запрещённую сеть. Каждый переход должен проходить ту же проверку.
Нужно ли показывать модели полный сетевой лог?
Обычно достаточно категории ошибки и безопасного пояснения. Токены, внутренние адреса и заголовки авторизации не следует раскрывать автоматически.