A10:2021 - Подделка запросов со стороны сервера (SSRF)

Обзор

Эта категория добавлена в Топ-10 опроса сообщества (#1). Данные показывают относительно низкий коэффициент встречаемости при охвате тестирования выше среднего. Поскольку новые записи, скорее всего, будут представлять собой единый или небольшой кластер перечней общих недостатков (CWE) для привлечения внимания и повышения осведомленности, есть надежда, что они будут сосредоточены и могут быть объединены в более широкую категорию в будущем.

Описание

Всякий раз возникают ошибки SSRF, когда веб-приложение извлекает удаленный ресурс без проверки предоставленного пользователем URL-адреса. Это позволяет злоумышленнику с помощью приложения отправить созданный запрос в неожиданное место назначения, даже если оно защищено брандмауэром, VPN или другим типом списка управления доступом к сети (ACL).

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

Как предотвратить

Разработчики могут предотвратить SSRF, реализовав некоторые или все следующие элементы управления по защите:

С сетевого уровня

• Разделить функции удаленного доступа к ресурсам в отдельных сетях для уменьшения влияния SSRF.
• Применяйте политику брандмауэра “deny by default” или правила контроля доступа к сети, чтобы блокировать весь трафик интернета, кроме необходимого.

Подсказки:
~ Установите владение и жизненный цикл для правил брандмауэра на основе приложений.

~ Регистрируйте все принятые и заблокированные сетевые потоки на брандмауэрах (см. A09:2021 - Ведение журнала безопасности и сбои мониторинга).

С прикладного уровня:

• Очищайте и проверяйте все входные данные клиента.
• Используйте схему URL-адреса, порт и пункт назначения с положительным списком разрешений.
• Не отправляйте необработанные ответы клиентам.
• Отключите перенаправление HTTP.
• Следите за согласованностью URL-адресов, чтобы избежать атак, например, повторная привязка DNS и условия гонки “время проверки до времени использования” (TOCTOU).

Не уменьшайте SSRF с помощью списка запретов или регулярного выражения. У злоумышленников есть списки полезных данных, инструменты и навыки для обхода списков запрещенных.

Дополнительные меры:

• Не развертывайте другие службы, связанные с безопасностью, на фронтальных системах (например, OpenID). Управляйте локальным трафиком в этих системах (например, localhost)
• Для интерфейсов с выделенными и управляемыми группами пользователей используйте сетевое шифрование (например, VPN) в независимых системах для высокого уровня защиты.

Примеры сценариев атак

Злоумышленники могут использовать SSRF для атаки на системы, защищенные брандмауэрами веб-приложений, брандмауэрами или сетевыми списками управления доступом, используя такие сценарии:

Сценарий №1: Сканирование портов внутренних серверов. Если сетевая архитектура несегментирована, злоумышленники могут составить карту внутренних сетей и определить, открыты или закрыты порты на внутренних серверах по результатам подключения или по времени, затраченному на подключение или отклонение полезных данных SSRF.

Сценарий №2: Раскрытие конфиденциальных данных. Злоумышленники могут получить доступ к локальным файлам (например, внутренней службы) для получения конфиденциальной информации, file:///etc/passwd</span> and http://localhost:28017/.

Сценарий №3: Доступ к хранилищу метаданных облачных служб. У большинства облачных провайдеров есть хранилище метаданных, http://169.254.169.254/. Злоумышленник может прочитать метаданные для получения конфиденциальной информации.

Сценарий №4: Компрометация внутренних служб. Злоумышленник может злоупотреблять внутренними службами для проведения дальнейших атак, например, удаленное выполнение кода (RCE) или отказ в обслуживании (DOS).