Kept | Cyber
Задать вопрос: cyber@kept.ru
Статистика обновлена 12.11.2026 в 21:57 · 1 просмотр страницы · Хотите больше просмотров?
Динамика за 30 дней
Истории пока нет. График появится после следующих обновлений статистики.
Рекламные публикации
Последние публикации
Все посты канала →Многие приложения умеют обращаться к ресурсам по ссылке: загружать изображение по URL, строить превью ссылки, принимать вебхуки, импортировать данные, формировать PDF из веб-страницы. Если адрес берется из пользовательского ввода и не проверяется должным образом, атакующий может подставить вместо внешней ссылки внутренний адрес.
Через SSRF атакующий может:
🔸 обращаться к внутренним сервисам и административным интерфейсам, недоступным из интернета;
🔸 разведывать внутреннюю сеть: какие узлы и порты в ней существуют;
🔸 получать данные из сервиса метаданных облачной платформы (например, адрес 169.254.169.254 для инфраструктуры AWS), в том числе временные ключи доступа;
🔸 в отдельных случаях перейти к выполнению команд во внутренних системах.
Показательный пример – инцидент в Capital One (2019 год). Через SSRF в веб-приложении получили облачные учетные данные, а с их помощью выгрузили данные порядка 100 млн клиентов.
В OWASP Top 10 редакции 2021 года SSRF занимала отдельную позицию A10. В редакции 2025 года ее включили в категорию A01 «Нарушение контроля доступа»: приложение доверяет адресу, который не должно было принимать.
Как защититься от SSRF-атак?
1️⃣ По возможности разрешать обращения только к заранее утвержденному списку доменов и протоколов (allowlist).
2️⃣ Проверять IP-адрес после разрешения доменного имени и блокировать внутренние, loopback- и link-local-диапазоны.
3️⃣ Ограничивать исходящий трафик серверов: сегментация сети и egress-фильтрация.
4️⃣ В облаке использовать защищенную версию сервиса метаданных (например, IMDSv2 в AWS) и выдавать сервисным ролям минимально необходимые права.
5️⃣ Не возвращать пользователю ответ внутреннего сервиса «как есть».