Перейти к содержимому
Все статьи
Безопасность

Загрузка картинки по URL: что защитить от SSRF

·27 октября 2026 г.· 6 мин чтения
Не уверены, что сайт чистый?Проверить сайт на взлом

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

Какую работу пользователь поручает серверу

Функция удалённого импорта выглядит как удобная замена загрузке файла. Но запрос делает сервер со своими сетевыми возможностями, а не браузер пользователя. В описании SSRF на MDN именно происхождение запросов из серверной среды является основой проблемы.

Это не означает, что всякая функция импорта автоматически уязвима. Нужно оценить её реализацию и необходимую область. Сначала запишите бизнес-задачу: изображения от известных поставщиков или произвольные публичные источники. У этих сценариев разные допустимые ограничения.

Если источники известны заранее

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

Если продукт допускает широкий набор публичных источников, нельзя просто назвать их все доверенными. Требуются отдельные сетевые ограничения и проверка назначений. OWASP SSRF Prevention рассматривает меры приложения и сетевого уровня как разные части защиты.

Учебная карта границ импорта

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

ГраницаРазрешённое поведениеГде проверяетсяРезультат отказаЧто фиксировать безопасно
Запрос пользователяИмпорт в рамках доступной ему функцииСлой приложенияПонятное отклонение без запуска произвольного полученияТип операции и причина
ИсточникТолько предусмотренный сценарий и допустимый адресРазбор адреса и политика источниковЗагрузка не начинаетсяКатегория решения без секретных параметров
СоединениеТолько разрешённые назначения и сетевые праваСреда получения и её сетьНедопустимое соединение не выполняетсяПроверяемое основание ограничения
ПеренаправлениеТолько по отдельно определённому правилуКлиент загрузкиАвтоматический уход на новый непроверенный адрес запрещёнФакт перехода и решение политики
ОтветОграниченные время, размер и ресурсы обработкиЗагрузчик и обработчикКонтролируемая остановкаКакая граница сработала
ПубликацияПодтверждённый допустимый результатЭтап сохранения изображенияНеподходящее содержимое не публикуетсяСтатус результата без лишних данных

Перенаправление меняет предмет проверки

OWASP предупреждает об автоматическом следовании перенаправлениям. Если функция не нуждается в них, безопаснее не разрешать их по умолчанию. Если они необходимы, каждый разрешённый переход должен оставаться в согласованной области и под проверяемыми ограничениями.

Нельзя проверить исходную строку, а затем без условий поручить клиенту пройти любую цепочку. Новое назначение является новым основанием решения. При этом эта статья не предлагает способы обхода фильтров: задача владельца — сохранить границы допустимого получения.

Имя и фактическое соединение нужно согласовать

Разрешение имени и установление соединения являются разными этапами. Данные о назначении могут меняться, поэтому проверка не должна описывать один результат, а соединение — использовать другой без контроля. Конкретный механизм зависит от клиента и сетевой архитектуры.

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

Для тестовой процедуры используйте собственные учебные ресурсы и допустимые маршруты. Не сканируйте внутренние системы и не проверяйте чужие адреса ради примера из статьи. Здесь такие проверки не выполнялись, а сеть сервера не исследовалась.

Какие полномочия не нужны загрузчику

Не передавайте внешнему источнику служебные cookie, токены приложения и другие данные только потому, что они есть у основного клиента. У загрузчика должна быть своя определённая задача. Право прочитать публичное изображение не предполагает право действовать от имени пользователя во всех системах компании.

Проверьте также, что именно попадёт в сообщение об ошибке и журнал. Полный адрес может содержать закрытый параметр доступа. Для разбора обычно нужны тип отказа, операция и безопасная связь с задачей; состав технических сведений выбирают осознанно.

Получение ответа ещё не означает готовую картинку

Проверьте фактическое содержимое и допустимость дальнейшей обработки, а не только слово в имени файла. Установите пределы времени, объёма и ресурсов. Если остановка произошла по одному из них, пользователь должен получить объяснимый статус без бесконечного повторения.

Сохранение и публикация являются отдельными этапами. Успешный сетевой запрос не должен автоматически означать, что результат размещён в каталоге. Иначе неподходящее содержимое получает статус изображения только по месту, куда его хотели загрузить.

Приёмка защитных границ

  1. Определите необходимую область источников и полномочия пользователя импорта.
  2. Проверьте политику адресов отдельно от фактических сетевых ограничений обработчика.
  3. Зафиксируйте допустимое поведение перенаправлений и разрешения имён.
  4. На собственных учебных ресурсах проверьте согласованные разрешения и контролируемые отказы.
  5. Проверьте пределы ответа, обработку результата и отсутствие утечки секретов в диагностике.
  6. Подтвердите, что публикация происходит только после нужных проверок результата.

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

Проверяемый итог — пользовательский URL запускает только предусмотренный процесс получения. Отсутствие очевидной ошибки в строке не доказывает этого результата без согласованной работы приложения, сети и обработки ответа.

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

С чего начать защиту загрузки по URL от SSRF?

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

Достаточно ли проверять исходный URL перед редиректом?

Нет, новое назначение тоже должно подчиняться согласованной политике. Если переходы не нужны функции, не разрешайте их автоматически; если нужны, отдельно ограничьте и проверяйте их.

Почему при защите SSRF нужно учитывать DNS?

Разрешённое имя и фактическое назначение соединения должны оставаться согласованными. Изменение результата разрешения не должно незаметно переносить получение в недопустимую область.

Нужна помощь с проектом?

Обсудим задачу и предложим решение — от сайта до SaaS и защиты.

Связаться