Подделка запросов на стороне сервера (SSRF) – это атака, которая позволяет злоумышленникам отправлять вредоносные запросы к другим системам через уязвимый веб-сервер. Эта уязвимость входит в список OWASP Top 10 как один из главных рисков безопасности приложений, который может привести к раскрытию информации и открыть путь к более опасным атакам (теперь в категории «Нарушение контроля доступа»). Ниже рассмотрен механизм работы SSRF, а также методы обнаружения и предотвращения таких угроз в веб-приложениях.
Введение в SSRF
Веб-приложения могут инициировать HTTP-запросы между серверами. Обычно они используются для получения удаленных ресурсов, таких как обновления программного обеспечения, или для импорта метаданных по URL либо из другого приложения. Такие межсерверные запросы в целом не представляют опасности, но при условии неправильной реализации могут привести к появлению SSRF.
Уязвимость подделки запросов на стороне сервера (SSRF) возникает, когда для формирования целевого URL используются данные, которые может контролировать пользователь. Для осуществления атаки злоумышленник изменяет значение параметра в уязвимом веб-приложении, чтобы создавать запросы или управлять ими со стороны сервера.
Внешние ресурсы, к которым обращается веб-приложение, могут включать внутренние сервисы (например, RSS-ленту с другого сайта). Для получения удаленной ленты разработчики могут использовать такой URL:
https://example.com/feed.php?url=externalsite.com/feed/to
Если злоумышленник сможет изменить параметр url на localhost (loopback-интерфейс), это позволит ему просматривать локальные ресурсы, размещенные на сервере, что делает их уязвимыми для SSRF.
- Возможность контролировать пункт назначения запросов на стороне сервера открывает пространство для множества вредоносных действий, в частности:
- Злоупотребление доверительными отношениями между уязвимым сервером и другими системами.
- Обход белых списков IP-адресов.
- Обход служб аутентификации на основе хостов.
- Чтение веб-ресурсов и других полезных активов, недоступных для публики (например, API метаданных в средах AWS или trace.axd в ASP.NET).
- Сканирование портов во внутренней сети, к которой подключен сервер.
- Чтение файлов с веб-сервера.
- Просмотр страниц состояния и взаимодействие с API от имени веб-сервера.
- Получение конфиденциальной информации (например, IP-адреса сервера, работающего за обратным прокси).
SSRF в OWASP Top 10
SSRF является хорошо известной уязвимостью и регулярно входит в список десяти главных рисков безопасности веб-приложений от Open Web Application Security Project (OWASP). В OWASP Top 10 за 2021 год она впервые получила собственную категорию – A10:2021 – Подделка запросов на стороне сервера (SSRF), на основе результатов опроса сообщества. На данный момент в OWASP Top 10 2025 эта категория включена в «Нарушение контроля доступа».
Поскольку современные веб-приложения становятся более сложными и взаимосвязанными, получение URL стало фундаментальной операцией для доставки контента и функциональности. С ростом количества запросов на стороне сервера такие уязвимости также участились. В то же время их масштаб и влияние расширяются из-за распространения облачных сервисов и сложных архитектур приложений, что позволяет злоумышленникам получать доступ к веб-инфраструктурам и источникам данных через скомпрометированный сервер.
Типичная эксплуатация уязвимости
В типичном сценарии злоумышленник, которому нужен доступ к внутреннему серверу, не может использовать прямые запросы, поскольку их заблокирует фаервол. Вместо этого он может использовать SSRF, чтобы провести атаку по следующему алгоритму:
- Нападающий отправляет поддельный запрос к уязвимому веб-серверу, который находится в одной внутренней сети с целевым сервером.
- Уязвимый веб-сервер пересылает контролируемый злоумышленником запрос к цели в обход фаервола.
- Целевой сервер отвечает запрашиваемыми данными.
- В зависимости от специфики уязвимости, информация отправляется обратно субъекту угрозы. Чаще всего эти данные приходится извлекать или выводить иными способами (out-of-band).
Почему SSRF опасна?
В то время как многие веб-уязвимости влияют непосредственно на целевую систему, SSRF позволяет использовать её в качестве посредника для отправки запросов к третьей системе. Хотя сама атака может не наносить прямого ущерба, она предоставляет доступ к внутренним системам, которые не должны быть доступны из Интернета. Есть несколько причин, почему это опасно.
SSRF злоупотребляет доверием между внутренними системами
Согласно лучшим практикам безопасности, поверхность атаки должна оставаться минимальной на всех уровнях. Во внутренних сетях это обычно означает, что доступ к определенным портам или действиям разрешен только отдельным доверенным машинам. Для поддержания безопасности с возможностью обмена данными и выполнения административных задач серверы часто имеют доверительные отношения с выбранными устройствами.
На уровне сети такое доверие может означать, что фаервол разрешает доступ к определенным портам, только если устройство находится в той же локальной сети или если его IP-адрес есть в белом списке. На уровне программного обеспечения может существовать неявное доверие к локальным машинам – для некоторых административных задач не требуется аутентификация, если IP-адрес 127.0.0.1 или принадлежит к внутренней сети. Это добавляет определенный уровень физической безопасности: даже получив действительные учетные данные, злоумышленник не сможет войти без доступа к локальной сети.
Благодаря SSRF злоумышленник может обойти такие ограничения и обращаться к другим серверам, которые доверяют скомпрометированной машине. Это открывает возможность доступа к внутренним данным или взаимодействия с портами, недоступными из внешней сети. Подделывая серверные запросы, внешний злоумышленник может выполнять вредоносные действия на целевом сервере, которые иначе были бы невозможны извне.
SSRF позволяет злоумышленникам сканировать локальные или внешние сети
Уязвимость позволяет сканировать локальные или внешние сети, к которым подключен сервер. Хотя прямое извлечение данных обычно невозможно, злоумышленники используют время загрузки страницы, сообщения об ошибках или баннеры исследуемой службы, чтобы косвенно определить, отвечает ли целевая служба и открыт ли проверяемый порт.
Пример: сканирование сети через SSRF уязвимость
Предположим, существует веб-сайт с сервисом для загрузки JPEG-изображений из удаленного источника с целью определения их размеров. В качестве контроля безопасности сервис проверяет наличие в ответе HTTP-заголовка Content-Type со значением image/jpeg. Если заголовок отсутствует или содержит иное значение, сервис возвращает ошибку «Пожалуйста, предоставляйте изображения только в формате JPEG». В случае проблемы с подключением возвращается сообщение «Изображение не найдено!».
Анализ реакции сервиса на различные входные данные:
- Запрос корректного изображения: https://victim.com/image.php?url=https://example.com/picture.jpg возвращает высоту и ширину. Это действительное изображение с правильным Content-Type.
- Запрос HTML-файла: https://victim.com/image.php?url=https://example.com/index.html. Сервис возвращает «Пожалуйста, предоставляйте изображения только в формате JPEG», поскольку страница имеет неправильный заголовок (text/html вместо image/jpeg).
- Запрос с недействительным URL: https://victim.com/image.php?url=https://example.invalid/ Возвращается «Изображение не найдено!», что означает ошибку получения ресурса.
Зная поведение приложения, злоумышленник может использовать его в своих целях. Поскольку действительный URL с отсутствующим или неправильным заголовком Content-Type возвращает определенную ошибку, можно отправить запрос с внутренним URL:
https://victim.com/image.php?url=127.0.0.1:3306
Получение ошибки «Изображение не найдено!» Будет означать отсутствие ответа от хоста 127.0.0.1 на порту 3306. Однако сообщение «Пожалуйста, предоставляйте изображения только в формате JPEG» будет свидетельствовать о том, что внутренний сервер ответил, а значит, на этом порту запущена служба. Таким образом, уязвимое веб-приложение можно использовать для проверки различных внутренних IP и портов, чтобы выполнить полное сканирование. Фактически такая SSRF-уязвимость позволяет злоумышленникам проводить сканирование портов без использования настоящего сканера портов.
SSRF может раскрывать файлы и внутренние ресурсы на сервере
Когда содержимое удаленного ресурса непосредственно рендерится на странице, возникает вероятность того, что злоумышленники смогут прочитать содержимое локальных файлов. Например, веб-сервис, который удаляет все изображения с предоставленного URL и форматирует текст. Для этого он берет тело ответа для заданного URL и применяет к нему текстовое форматирование.
Если такой сервис позволяет передавать URL file:// вместо обычных http:// или https://, это можно использовать для доступа к локальной файловой системе. Например, URL file:///etc/passwd в UNIX-системе отобразит содержимое файла passwd. Эта же техника подходит для просмотра исходного кода самого веб-приложения.
Потенциальные последствия атак
Как видно из приведенных выше примеров, прямым последствием эксплуатации SSRF почти всегда является раскрытие информации, поскольку злоумышленники получают много полезных данных о системах и ресурсах, которые должны быть для них недоступны. Однако косвенные последствия могут быть значительно серьезнее и позволяют злоумышленникам:
- Использовать уязвимый сервер как сканер портов и IP-адресов для внутренних и внешних систем.
- Взаимодействовать с протоколами наподобие Gopher (если включено) для дополнительной разведки.
- Обнаруживать IP-адреса серверов с помощью обратного прокси.
Получать удаленное выполнение кода.
Поскольку SSRF в первую очередь является каналом доступа для дальнейшей разведки и атак, возможны и многие другие сценарии. Они зависят от того, как уязвимое веб-приложение использует ответы, полученные от удаленного ресурса. В сочетании с другими уязвимостями и при соответствующих условиях SSRF может иметь серьезные последствия.
Предотвращение SSRF
Для предотвращения подобных угроз настоятельно рекомендуется использовать белые списки (allowlists) разрешенных доменов и протоколов для удаленных ресурсов, получаемых веб-сервером. В целом следует избегать прямого использования введенных пользователем данных в любых функциях, которые могут делать запросы от имени сервера. Хотя очистка и фильтрация ввода является хорошей практикой, на них не стоит полагаться как на единственный метод защиты – охватить все возможные сценарии обхода практически невозможно.
Для обхода фильтрации URL могут использоваться разнообразные методы:
- Применение закодированных IP-адресов, которые транслируются в локальные (например, 1 или 123.123.123 эквивалентны localhost).
- Использование имен хостов, которые преобразуются во внутренние IP.
- Обход черных списков хостов путем добавления точек в конце имени.
Это лишь небольшая часть инструментов для обхода, поэтому главной рекомендацией остается избегание ввода непроверенных данных в функциях, генерирующих серверные запросы.
Обнаружение SSRF уязвимостей в веб-приложениях
Современные решения для динамического тестирования безопасности приложений (DAST), такие как Invicti (на базе Acunetix и Netsparker), могут обнаруживать многие уязвимости подделки запросов на стороне сервера (SSRF) во время работы приложения, включая такие как out-of-band.
Для более раннего обнаружения в процессе разработки очень полезными являются инструменты статического тестирования безопасности приложений (SAST), например, от Mend.io.
Invicti и Mend.io имеют безупречную интеграцию для централизованного управления уязвимостями. Если вы хотите протестировать любое из этих решений бесплатно, пожалуйста, оставьте свои контактные данные в форме ниже.
