Механизм эксплуатации (кратко)
- Веб‑приложение получает URL изображения и сервер делает HTTP(S)-запрос от своего имени. Злоумышленник подставляет URL, который резолвится на внутренние ресурсы или специальные адреса (metadata, базы, сервисы управления), или на контролируемый им DNS для эксфильтрации.
- Возможные атаки: доступ к службам в VPC, чтение метаданных (например AWS IMDS по адресу $\text{169.254.169.254}$), обход аутентификации, доступ к внутренним API, удалённая загрузка вредоносного контента, сканирование портов через последовательные запросы, DNS‑туннелирование для утечки данных.
- Типичный вектор: внешний URL → редиректы → резолв к приватному IP → сервер запрашивает ресурс → злоумышленник получает ответ/токен/выполняет SSRF.
Уровни защиты (по степени надёжности, применить все вместе)
1) Входная валидация и базовые проверки
- Парсить URL строго: схема, хост, порт; запрещать нестандартные схемы (file://, gopher://, ftp:// и т.п.).
- Не доверять DNS‑именам без резолюции: резолвить и сравнивать IP.
- Блокировать адреса/диапазоны: проверять, что конечный IP не принадлежит приватным диапазонам $\{\text{10.0.0.0/8},\text{172.16.0.0/12},\text{192.168.0.0/16},\text{127.0.0.0/8},\text{169.254.0.0/16}\}$.
- Проверка редиректов: лимитировать число редиректов и запрещать редиректы на приватные адреса.
- Ограничения по таймаутам, размеру ответа и MIME‑типу (принимать только допустимые image/*).
Пример логики проверки (упрощённо):
- Разрешать только URL с схемой http(s).
- Резолвить хост $\Rightarrow$ получить IP.
- Если $ip\in R_{\text{private}}$ — отклонить.
2) Белые списки (allowlist)
- Предпочтительнее, чем блоклисты: разрешать только заранее доверенные домены/каталоги CDN.
- Для динамики — поддерживать управляемый список и механизмы утверждения новых доменов.
- Проверять effective TLD + 1 (например example.com), избегать подмен через unicode/IDN.
3) Прокси/прокси‑роутинг запросов
- Все внешние загрузки проходят через контролируемый прокси/сервис (image proxy, fetcher) с жёсткими правилами:
- отдельный процесс/сервис без доступа к внутренней сети,
- egress только к разрешённым адресам,
- блокировка заголовков аутентификации, отключение cookie forwarding,
- отключены TLS client auth и WebDAV, запрет HTTP methods, лимит редиректов, время и размер.
- Логирование и метрики запросов через прокси для детекции аномалий.
4) Сетевые ACL и firewall
- На уровне облака/сети запретить egress приложений к приватным подсетям и метадате (например на уровне security groups, network ACL).
- Явно запретить доступ к адресам метаданных ($\text{169.254.169.254}$) и управления инфраструктурой.
- Минимизировать разрешённый исходящий трафик: принцип наименьших привилегий.
5) Контейнеризация и изоляция выполнения
- Выполнять парсинг/обработку внешних данных в изолированных рантаймах: отдельные контейнеры/песочницы с сетевым namespace, где egress сильно ограничен.
- Песочницы — непривилегированные контейнеры, seccomp, AppArmor/SELinux, ограничение CPU/RAM, read‑only файловая система.
- Эпхемерные инстансы: минимальное время жизни, авто‑перезапуск из доверенного образа.
Дополнительные защитные меры
- Отдельный сервис для загрузки/кеширования изображений (не основное приложение).
- Проверка содержимого (magic bytes) и безопасные библиотеки обработки изображений; обновления и фиксирование версий.
- Не выполнять парсинг/рендеринг опасных форматов; использовать безопасные преобразователи.
- Лимиты скорости на количество внешних URL/пользователя и аномальная активность.
Защита цепочки поставок
- Пакеты и зависимости:
- Использовать lock‑файлы и фиксированные версии; ревью изменений в зависимостях.
- Включить подписанные пакеты и репозитории (например подписанные артефакты, GPG подписи).
- Автоматический скан CVE и SCA (software composition analysis).
- Минимизировать количество внешних зависимостей.
- Контейнерные образы и бинарники:
- Создавать SBOM для образов и артефактов.
- Подписывать образы (например cosign, Notary) и проверять подпись при деплое.
- Сканирование образов на уязвимости и malware, запрет запуска неподписанного/несканированного образа.
- Использовать минимальные базовые образы, регулярно обновлять.
- Инфраструктура CI/CD:
- Изолировать секреты, проходить статический/динамический анализ в pipeline.
- Ограничивать доступ к реестрам и подписыванию (многофакторная авторизация).
- Рутинные проверки целостности и периодические аудиты поставщиков.
Процедуры реагирования на инцидент (SSRF/компрометация внутренней сети)
1) Обнаружение и первичная оценка
- Индикаторы: неожиданный исходящий трафик к приватным IP, обращения к $\text{169.254.169.254}$, аномальные DNS‑запросы, повышенные ошибки/латентность.
- Собрать логи прокси/веб/сетевые/диплен‑файлы, метаданные контейнеров и трассировки вызовов.
2) Содержать (containment)
- Изолировать компрометированный сервис: отключить egress, остановить контейнеры/процессы или переключиться на read‑only режим.
- Блокировать подозрительные маршруты/адреса на уровне сети/фаервола.
- При подозрении на утечку ключей — отозвать креденшелы, rotate ключей/токенов, пересоздать IAM роли.
3) Сбор улик и анализ (forensics)
- Снэпшоты хостов/контейнеров, экспорт памяти при возможности, захват сетевого трафика, сохранить логи.
- Проанализировать URL/пейлоады, DNS‑записи, последовательность редиректов, время и источник запросов.
- Оценить воздействие: какие сервисы/данные могли быть доступными, были ли получены токены, выполнен ли код.
4) Устранение (eradication)
- Закрыть уязвимость в коде (строгая валидация/беконфигурирование прокси/ACL).
- Заменить и переустановить подозрительные образы из доверенного источника.
- Rotate секретов, пересоздать сессии/токены, обновить политики доступа.
5) Восстановление (recovery)
- Возвратить сервисы из проверенных образов/бэкапов, постепенно восстановить egress под контролем.
- Мониторить поведение после восстановления; усилить логирование и алерты.
6) Постинцидентный разбор (lessons learned)
- Документировать вектор, корневую причину, исправления.
- Обновить SOP, тесты, автоматические правила (ACL, allowlist, CI‑checks).
- Провести ретесты и tabletop‑упражнения; уведомить заинтересованных (внутренние/внешние согласно политике соблюдения).
Краткое резюме
- SSRF через загрузку изображений — частая уязвимость: защита должна быть многослойной: строгая валидация + allowlist, все внешние загрузки через контролируемый прокси/песочницу, сетевые ACL/ограничения egress, безопасная контейнеризация, и защита цепочки поставок (подписи, SBOM, сканирование). План реагирования должен включать быстрый containment, forensic, rotate секретов и восстановление из доверенных артефактов.