SSRF-атака: что такое подделка серверных запросов и как от нее защититься

Все начинается с простой функции. Представьте, что в приложении нужно указать ссылку на картинку, чтобы сервер скачал ее и отобразил в вашем профиле. Вы вводите URL, например:

Сервер исполняет вашу просьбу — загружает картинку с котиком и добавляет ее в ваш профиль. В обычной ситуации все так и работает.

А теперь представим, что в этой системе есть небольшая уязвимость: сервер доверяет любому указанному адресу и не подозревает, что его могут обмануть. А что будет, если вместо ссылки на картинку с котиком вы укажете, например, такой адрес:

Представьте, что сервер — сотрудник на ресепшене, который выполняет любые запросы: скачивает документы с другого сайта, отправляет запросы другим серверам, передает данные. Но что, если этим воспользуется злоумышленник?

SSRF-атака позволит ему управлять запросами сервера и получать доступ к внутренним ресурсам, которые изначально не предназначены для внешних пользователей.

Вот чем опасна SSRF-атака:

• Взлом внутренней сети. Обычно сервер находится в защищенной зоне, доступ к которой ограничен. Но с помощью SSRF-атаки злоумышленник может подключиться к базе данных и получить конфиденциальную информацию, например, план офиса или расположение ключевых систем.
• Кража важной информации. В облачных средах сервер может хранить ключи доступа, токены или учетные данные. SSRF позволяет злоумышленнику перехватить их и использовать для взлома.
• Запуск дополнительных атак. SSRF часто становится первой ступенью более сложных атак. С его помощью можно выявить уязвимости в локальных сервисах, выполнить команды на сервере или развернуть вредоносный код.

Если такая атака приводит к компрометации персональных данных, для компании это может обернуться не только инцидентом, но и регуляторными последствиями. Подробнее об этом читайте в статье «Утечки персональных данных в 2026 году: ответственность, оборотные штрафы и как снизить регуляторные риски».

Мы рассмотрели классическую SSRF-атаку, когда злоумышленник заставляет сервер выполнять запросы к ресурсам, к которым он имеет доступ, но которые недоступны обычным пользователям.

Но есть и другие виды SSRF-атак, их можно классифицировать в зависимости от целей и методов реализации:

Cloud SSRF

Этот тип атак актуален для серверов, которые работают в облачной инфраструктуре, например, AWS, Google Cloud или Azure.

В таких системах каждому серверу предоставляется доступ к специальному интерфейсу метаданных — панель управления, которая позволяет серверу получить информацию о его конфигурации.

Например, в AWS метаданные доступны по фиксированному адресу:

Представьте, что злоумышленник обнаруживает SSRF-уязвимость и подставляет этот URL в запрос, который сервер выполняет. Сервер загружает данные и возвращает их злоумышленнику. Метаданные могут содержать ключи доступа IAM, которые позволяют управлять всем облаком: удалять ресурсы, изменять конфигурации и скачивать данные из хранилищ.

С помощью такой атаки злоумышленник может использовать отключить системы, украсть данные и даже начать майнить криптовалюту на оборудовании компании.

Reconnaissance SSRF

Этот тип атак используется для разведки, когда основная цель злоумышленника — составить карту корпоративной сети. В таких атаках сервер выполняет роль проводника: он может взаимодействовать с любыми адресами внутри защищенной инфраструктуры, которые недоступны напрямую из интернета.

Представьте, что злоумышленник отправляет серверу серию запросов, последовательно сканируя диапазоны внутренних IP-адресов:

По ответам сервера можно определить, какие ресурсы доступны, какие порты открыты и какие службы активны. Например, если запрос к адресу возвращает ошибку 403 Forbidden, это может означать, что ресурс существует, но требует авторизации. Эти данные помогают злоумышленнику спланировать следующую атаку.

Redirect-Based SSRF

Этот тип атак используется, когда злоумышленники находят уязвимости в том, как сервер обрабатывает перенаправления на другие адреса. Например, сервер может принять запрос вида:

Сначала он попытается загрузить контент с внешнего адреса example.com, но затем, следуя редиректу, перенаправит запрос к внутреннему ресурсу 127.0.0.1/admin.

Такие атаки сложнее определить, так как запрос выглядит безобидным, а конечная цель скрыта за редиректом. Этот метод помогает обойти фильтры и проверки безопасности, которые блокируют прямое обращение к внутренним адресам.

External SSRF

Этот тип атак используется, когда цель злоумышленника — использовать сервер для взаимодействия с внешними системами, например, для рассылки спама или проведения DDoS-атак.

Например, он может передать серверу ссылку на вредоносный адрес, чтобы запустить массовую рассылку спама или организовать DDoS-атаку. Ссылка может выглядеть так:

С точки зрения внешней системы, все действия будут исходить с IP-адреса компании-владельца уязвимого сервера, а не злоумышленника.

Такой метод может использоваться не только для атаки на другие системы, но и для маскировки: вредоносный контент будет распространяться от имени легитимного сервера.

Blind SSRF

Этот тип атак возникает, когда сервер не возвращает данные напрямую злоумышленнику, но это не означает, что атака не приносит результатов.

Он не видит ответа на свои запросы, но может использовать уязвимость для выполнения действий, которые приведут к нежелательным последствиям. Например, злоумышленник может использовать Blind SSRF для отправки уведомлений через сторонние сервисы, изменения состояния сервисов или для выполнения действий, которые могут вызвать отказ в обслуживании (DoS).

Чтобы защититься от SSRF-атак, важно ограничить выполнение небезопасных запросов на уровне серверных настроек и учитывать возможные векторы атак при разработке приложений.

Проверяйте входные данные

Самая распространенная ошибка — доверять тому, что присылает пользователь. Чтобы предотвратить SSRF-атаки:

• Ограничьте доступные схемы URL. Разрешайте только те схемы, которые действительно нужны: например, http и https. Заблокируйте другие, такие как file, ftp, gopher, dict.
• Проверяйте формат URL. Используйте регулярные выражения или специальные библиотеки, чтобы убедиться, что URL записан корректно.

Работайте только с проверенными адресами

Если сравнивать сервер с сотрудником, который выполняет задачи только по инструкции, предоставьте ему белый список разрешенных адресов — сайтов, с которыми он может взаимодействовать.

Например, если сервер должен обращаться только к API партнера, в белом списке будет указан только его домен. Это исключает возможность отправки запросов на произвольные адреса.

Ставьте под запрет локальные адреса

Злоумышленники могут использовать сервер для доступа к внутренней инфраструктуре: корпоративному API, административным панелям или метаданным облака. Эти ресурсы обычно расположены по локальным IP-адресам, например:

• 127.0.0.1 — localhost;
• 192.168.x.x — ваша локальная сеть;
• 169.254.169.254 — метаданные облачных систем, таких как AWS.

Чтобы сервер не смог обращаться к этим адресам, нужно заблокировать диапазоны локальных IP-адресов в коде и настроить брандмауэр, чтобы он не позволял серверу связываться с внутренними ресурсами.

Минимизируйте права сервера

Даже если злоумышленник получит доступ к закрытым ресурсам, последствия атаки зависят от привилегий сервера. Если у него минимальные права, он не сможет нанести серьезный ущерб.

Вот что нужно сделать:

• Ограничьте доступ к облачным данным, если серверу он не нужен.
• Разрешайте взаимодействие только с необходимыми внешними системами.
• Разделяйте функционал: сервер, который обрабатывает пользовательские запросы, не должен иметь прямого доступа к базе данных.

Чем меньше у сервера прав, тем меньше возможностей для атаки.

Устанавливайте таймауты и лимиты

Когда сервер выполняет запросы, он может зависнуть на слишком долгом ответе или загрузить огромный файл. В SSRF-атаках злоумышленники используют это, чтобы перегрузить систему.

Как защититься:

• Установите таймаут на каждый запрос. Если сервер не получил ответ за несколько секунд, он должен прервать соединение.
• Ограничьте максимальный размер загружаемых данных, например, 1 МБ. Это предотвратит скачивание больших файлов, которые могут замедлить работу системы.

Это поможет избежать сбоев из-за долгих или ресурсоемких запросов и предотвратит попытки злоумышленников перегрузить сервер.

Используйте умные инструменты

Применяйте современные технологии для защиты от SSRF-атак:

• WAF (Web Application Firewall). Такие инструменты, как Cloudflare или AWS WAF, автоматически выявляют и блокируют атаки, включая SSRF.
• Изолированные окружения (песочницы). Подозрительные данные можно загрузить в изолированное окружение, например, контейнер или виртуальную машину, чтобы минимизировать риски.

Эти решения добавят дополнительный уровень защиты и снизят вероятность успешной атаки.

На платформе Start EDU на реальных кейсах показываем, как работают SSRF-атаки и как защитить пользователей. А еще даем задания на поиск уязвимостей в приложениях с учетом разных языков программирования и фреймворков. Запишитесь на бесплатное демо, и наш эксперт расскажет, как Start EDU помогает продуктовым командам писать безопасный код и выпускать защищенные продукты.

Но даже если команда знает, что такое SSRF, этого недостаточно: в безопасности важны не только знания, но и умение применять их в реальной работе. Почему обучение по ИБ не всегда дает нужный результат, разбираем в статье «Почему обучение сотрудников информационной безопасности не работает и что с этим делать в 2026».

Вот что разработчикам и администраторам нужно помнить, чтобы обезопасить сервер от SSRF-атак:

• Правильная обработка входных данных защищает сервер от выполнения нежелательных запросов.
• Ограничение прав сервера и настройка доступов снижают риск потенциального ущерба.
• Белые списки и блокировка локальных адресов предотвращают доступ к внутренним ресурсам.
• Автоматизация защиты с помощью WAF и других инструментов помогает оперативно обнаруживать угрозы.