Многие веб-приложения умеют работать с URL: скачивать изображения, импортировать данные, проверять страницы, отправлять вебхуки. Пользователь указывает адрес, а сервер выполняет запрос. Но если такую функцию спроектировать неправильно, то через нее можно обратиться к ресурсам, которые не должны быть доступны обычному пользователю. В статье рассказываем, когда возникает риск SSRF и что нужно сделать, чтобы защитить сервер от нежелательных запросов.
Что такое SSRF
SSRF (Server-Side Request Forgery, подделка запросов на стороне сервера) — уязвимость, при которой злоумышленник заставляет сервер отправлять произвольные сетевые запросы от своего имени. В результате сервер становится посредником между хакером и внутренними ресурсами приложения.
Например, пользователь отправляет в чат ссылку на статью. Сервис автоматически открывает страницу, чтобы получить заголовок, описание и изображение для превью.
Если без проверки переходить на каждый полученный URL, может возникнуть уязвимость SSRF. Вместо публичной статьи пользователь может отправить адрес другого ресурса — внутреннего тестового API или сервиса метаданных облачного провайдера. Эти данные закрыты извне, но доступны из сети приложения.
В этом и заключается опасность SSRF: такой запрос потенциально позволяет обратиться к внутренним сервисам. Злоумышленник может получить данные, которые не должны быть доступны извне.
Последствия SSRF зависят от конкретной конфигурации. Сам факт наличия уязвимости SSRF еще не означает, что злоумышленник автоматически получит доступ ко всей внутренней инфраструктуре. Многое зависит от того, к каким ресурсам может подключаться сервер, какие данные они возвращают и какие права есть у самого приложения.
Где в приложении может появиться SSRF
SSRF возникает не только там, где пользователь явно вводит URL. Потенциальный риск создает любая функция, которая получает адрес и затем самостоятельно обращается к нему. Например:
- Загрузка файлов по ссылке. Пользователь указывает адрес изображения или документа, а сервер скачивает файл и сохраняет его в приложении.
- Превью веб-страниц. Сервис получает URL веб-сайтов, открывает их и формирует скриншот или превью.
- Импорт данных. Приложение загружает данные из внешнего API или файла по указанному адресу.
- Вебхук. Пользователь или администратор задают URL, на который сервис должен отправлять уведомления о событиях, например создании заказа или успешной оплате.
- Интеграции с внешними сервисами. Приложение обращается к внешнему API по адресу, который задает сам пользователь.
- Проверка доступности ресурса. Сервис проверяет, отвечает ли указанный URL и какой статус возвращает сервер.
Сам по себе любой из этих сценариев не означает, что в приложении есть SSRF. Риск появляется, если пользователь может влиять на адрес назначения, а приложение не контролирует, куда именно отправляется запрос.
Как безопасно тестировать SSRF
Чтобы проверить уязвимость к SSRF, достаточно подготовить небольшую тестовую среду, которая повторяет нужный сценарий.
Можно поднять тестовое приложение, отдельный HTTP-сервер и внутренний сервис, который недоступен напрямую из внешней сети. Внешний сервер нужен, чтобы увидеть, действительно ли приложение отправляет запрос. Внутренний сервис помогает проверить, может ли приложение обратиться к закрытому ресурсу.
Тестирование рекомендуется проводить в несколько этапов:
- Найдите функции, которые обращаются к внешним ресурсам. Сначала нужно посмотреть, где приложение получает от пользователя URL и другие данные, по которым формируется сетевой запрос. Это могут быть поля для загрузки файлов по ссылке, настройки вебхуков, параметры интеграций или импорта данных.
- Узнайте, кто выполняет соединение. Важно убедиться, что обращение к указанному адресу выполняет именно сервер приложения, а не браузер пользователя. Для этого укажите адрес собственного тестового HTTP-сервера и посмотрите логи. Если в них появляется запрос после действия пользователя, значит, соединение установил сервер приложения.
- Проверьте доступ к внутреннему сервису. Укажите в приложении адрес тестового внутреннего сервиса. Если приложение получит от него ответ, значит, сервер может обращаться к ресурсам, которые недоступны пользователю напрямую.
- Изучите ограничения. Важно понять, что именно разрешает приложение. Проверьте протоколы, порты, локальные и приватные адреса, внутренние подсети. Дополнительно посмотрите, что именно происходит при перенаправлении на другой адрес и проверяется ли конечное назначение после редиректа.
- Проверьте защиту. Если тест показал проблему, внесите изменения и заново повторите те же сценарии.
Помните, что тестировать SSRF на работающем приложении опасно: запросы могут затронуть реальные данные, сервисы и компоненты инфраструктуры. Лучше заранее подготовить отдельную среду, где можно проверить запросы без последствий для пользователей и продукта.
Защита от SSRF: какие методы реально работают
Для надежной защиты от SSRF важно иметь несколько уровней защиты. Даже если одна проверка не сработает, другие помогут минимизировать последствия.
Что можно сделать:
- Разрешите только необходимые адреса. Если приложение должно обращаться к небольшому числу внешних сервисов, можно использовать allowlist — список разрешенных доменов и ресурсов, — а все остальные назначения блокировать.
Такой подход работает надежнее, чем blacklist, где приложение пытается перечислить все опасные варианты: localhost, приватные IP-адреса и другие служебные диапазоны.
- Проверяйте не только строку URL. Простого поиска запрещенных слов или проверки регулярным выражением недостаточно для защиты от SSRF. Лучше использовать стандартный URL-парсер и отдельно проверять адрес, порт, протокол и конечное назначение запроса.
- Ограничьте протоколы. Если приложение работает только с веб-адресами, разрешите ему обращаться только по HTTP и HTTPS. Чем меньше способов инициировать исходящее соединение, тем меньше риск атаки.
- Контролируйте исходящий трафик. Сервер не должен иметь свободного доступа ко всей внутренней сети. Можно ограничить исходящие порты и запретить приложению подключаться к административным интерфейсам, ненужным подсетям.
- Ограничьте редиректы. Даже если исходный URL прошел проверку, сервер может получить перенаправление на другой адрес. Поэтому нужно контролировать конечное назначение запроса. Если функция не требует автоматических редиректов, их можно отключить. Если они нужны, каждый новый адрес также должен проходить проверку.
- Установите минимальные права. Для облачных приложений и внутренних сервисов важно ограничить права учетных данных, доступных приложению. Тогда злоумышленник не сможет получить доступ ко всем ресурсам даже при успешной SSRF-атаке.
- Используйте сетевое разделение. Например, можно создать отдельную сетевую зону для веб-сервера и отдельную зону для базы данных и административных сервисов. Разрешите между ними только необходимые соединения.
Помните, что защиту от SSRF важно проверять не только после внедрения, но и после каждого обновления. Новая интеграция, вебхук или функция загрузки данных могут изменить правила исходящих запросов и снова создать нежелательный доступ.
Почему простые защиты от SSRF не всегда работают
SSRF часто пытаются предотвратить с помощью отдельных фильтров, но одного такого ограничения недостаточно.
Для надежной защиты от SSRF используют несколько уровней проверок. Приложение должно проверять адрес на разных этапах обработки запроса, а сетевые ограничения — не позволять серверу подключаться к ненужным внутренним ресурсам.
Главное про SSRF
- SSRF-уязвимость возникает, когда пользователь может указать адрес, к которому обращается сервер, и получить доступ к ресурсам, недоступным извне.
- Риск SSRF создают разные функции приложения: загрузка файлов по ссылке, превью страниц, импорт данных, вебхуки и другие серверные запросы.
- Надежная защита от SSRF включает allowlist, разбор адреса, ограничение протоколов и редиректов, контроль исходящего трафика.
- Одиночные фильтры не помогут защититься от SSRF, важно использовать несколько уровней проверок.
- SSRF стоит тестировать только в тестовой среде, чтобы не подвергать риску пользователей и продукт.
FAQ
Всегда ли SSRF позволяет получить доступ к внутренней сети?
Нет, последствия атаки зависят от сетевой архитектуры, прав приложения и настроек исходящего трафика. В одном случае сервер может иметь доступ только к нескольким внешним API, в другом — к значительной части внутренней инфраструктуры.
Достаточно ли запретить localhost?
Нет, это только один из вариантов адреса, который может быть недоступен пользователю, но доступен серверу. Защита должна контролировать фактическое назначение запроса и учитывать сетевую конфигурацию приложения.
Опасна ли SSRF для облачных приложений?
Да, потому что в облачной инфраструктуре могут быть доступны metadata-сервисы, которые предоставляют служебную информацию: сведения о конфигурации, временные учетные данные. Это может привести к раскрытию чувствительной информации и личных данных пользователей.
Как проверить приложение на SSRF?
Начните с функций, которые принимают URL или другие данные для формирования исходящих запросов. В тестовом окружении направьте их на собственные контролируемые сервисы и проверьте, какие адреса, протоколы, порты и редиректы приложение разрешает.
Можно ли полностью защититься от SSRF attack одной проверкой URL?
Надежнее использовать несколько уровней защиты: разбор и валидацию URL, allowlist, ограничения протоколов и редиректов, минимальные права приложения.
