🎯 SSRF: Как хакер заставляет сервер атаковать самого себя
Кратко: Представьте, что вы звоните в службу доставки и говорите: «Заберите посылку по адресу 1». Курьер едет по адресу 1. А теперь представьте, что вы говорите: «Заберите посылку по адресу моего сейфа внутри вашего офиса». Если служба доставки слепо слушается, курьер откроет сейф. SSRF (Server-Side Request Forgery) — это когда вы заставляете сервер выполнять HTTP-запросы туда, куда хотите вы, а не туда, куда нужно разработчику . Это как иметь пульт управления чужим компьютером, но с одной кнопкой — «сходить по ссылке».
▫️ Как это работает (уязвимое место) Разработчики часто пишут код, который по запросу пользователя ходит на другой сайт. Например, чтобы показать превью статьи или скачать аватарку по ссылке . Вот как выглядит плохой код: def fetch_image(): user_url = request.GET['url'] # Пользователь говорит: "Скачай картинку с example.com" image = requests.get(user_url) # Сервер покорно идёт по ссылке return image Проблема: user_url доверяют без проверки. Что может прийти от хакера: · http://169.254.169.254/latest/meta-data/ — запрос к секретному облачному серверу, который выдаёт ключи доступа к вашей AWS-инфраструктуре . · http://localhost:8080/admin — запрос к внутренней админке, которая не должна быть доступна из интернета, но сервер может к ней обратиться . · file:///etc/passwd — запрос к локальным файлам сервера .
▫️ Классические мишени: внутренняя сеть Когда сервер живёт внутри корпоративной сети, он видит то, что скрыто от внешнего мира: панели управления базами данных, Docker API, внутренние сервисы. SSRF превращает сервер в шпиона, который по вашему приказу ходит и подсматривает эти внутренние ресурсы . Стандартные цели атак : · Loopback (127.0.0.1, localhost) — серверные службы, висящие на локалхосте. · Private IP (192.168.x.x, 10.x.x.x, 172.16.x.x) — внутренняя сеть компании, куда обычный пользователь не имеет доступа. · http://192.168.1.1/admin — внутренняя админка роутера. · http://169.254.169.254 — точка доступа к метаданным облака (где лежат секретные ключи). · Узнавать внутреннюю структуру — порты, которые открыты внутри сети.
▫️ Слепой (Blind) SSRF: атака вслепую Бывает, что сервер ходит по ссылке, но не возвращает вам результат. Например, конвертирует веб-страницу в PDF и отправляет по почте. Вы не видите содержимое localhost, но видите факт выполнения. В этом случае используют OOB (Out-of-Band) технику. Хакер заставляет сервер сходить на свой уникальный домен attack.evil.com. По тому, что сервер обратился на этот домен, он понимает — уязвимость есть .
▫️ Реальный кейс (2026 год) LMDeploy — toolkit для работы с большими языковыми моделями (LLM). Хакеры нашли SSRF-уязвимость: модель могла по запросу пользователя загружать картинку из интернета для анализа. Но load_image() не проверяла, куда именно идёт запрос . Через 13 часов после публичного раскрытия хакеры уже вовсю сканировали серверы : · Спрашивали секреты у AWS Metadata Service (169.254.169.254). · Сканировали порты внутренних сервисов (Redis, MySQL). · Пытались связаться с командным центром (C2). Это не просто теория — это то, что происходит прямо сейчас, пока вы читаете этот пост.
▫️ Как защититься (чтобы вас не взломали) 1. Белый список (Allowlist): Самый надёжный способ. Разрешить ходить только туда, куда нужно: https://api.trusted.com/*. Всё остальное — запретить . 2. Запретить протоколы: Не разрешать file://, gopher://, dict://. Отключать всё, кроме https:// . 3. Изоляция: Сервер, который ходит по внешним ссылкам, должен жить в отдельной, бедной сети, где нет ничего ценного. 4. Не доверять пользовательскому вводу: Валидировать, экранировать, проверять . Главная идея: SSRF — это атака на доверие. Сервер не должен доверять ссылкам от незнакомцев.
