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

Атака, при которой злоумышленник добавляет или изменяет параметры URL-адреса, называется подделкой запросов со стороны сервера (англ. Server-side request forgery, SSRF). В результате у злоумышленника появляется возможность инструктировать сервер либо получить информацию или доступ, которыми он не должен владеть. SSRF можно использовать для вызова внутренних API или доступа к базам данных. Приложение, уязвимое к такой атаке, – словно окно прямо в сеть с обходом периметра защиты: ужасная ситуация.

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

Рис. 5.2. Блок-схема SSRF-атаки

Защита (предотвращение атаки) и смягчение (уменьшение вреда, если атака все-таки произошла) состоят из нескольких уровней.

Защита

1. Не использовать параметры URL для построения вызовов внутри приложения или сети, так как ими можно легко манипулировать. По возможности вообще избегать их использования.

2. Выполнять проверку вводимых данных (используя «белый список»), как указано в предыдущих главах.

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

4. Использовать фильтрацию запросов, если она доступна в стеке. Подобно кодированию вывода, эта технология позволяет убедиться, что HTTP-ответы не содержат ничего опасного (например, SSRF-атаку). Если она недоступна, необходимо самостоятельно проверять, не содержат ли ответы того, что было отправлено в запросе (пользовательский ввод), в неизменном виде. Данные должны быть проверены перед добавлением в ответ. Нет необходимости отражать эту информацию в неизменном и непроверенном виде.

5. Отключать неиспользуемые схемы URL, такие как file:///, dict://, ftp:// и gopher://. Если они не используются, то должны быть отключены.

6. Создать специализированные модульные тесты для проверки на данную уязвимость.

7. Нанять опытного тестировщика безопасности ПО, который проверит наличие этой уязвимости во всех приложениях.

Смягчение

1. Использовать конструкцию нулевого доверия в сети и приложениях, чтобы приложение было ограничено в доступе к другим областям сети и другим приложениям.

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

3. Следовать руководству по усилению защиты для каждого веб-сервера, PaaS или контейнера, на котором размещены веб-приложения. Всегда следовать всем руководствам по усилению защиты.

4. Обращаться с попытками атак так же, как и с любым другим неправильным вводом: выдавать неясное сообщение об ошибке. Никогда не следует отражать информацию об атаке на экране или в ответе.

5. Все внутренние службы должны требовать прохождения аутентификации (например, старые версии MongoDB не требовали аутентификации или авторизации для доступа к базе данных).

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

За последние несколько лет участились случаи SSRF-атак, поскольку появилось больше информации о них. Хотя этот тип атак не входит в Топ-10, он заслуживает отдельного упоминания из-за своей опасности и распространенности.

ПРИМЕЧАНИЕ. При SSRF-атаке злоумышленник способен выдать инструкции веб-серверу (прочитать данные или выполнить вызов определенных функций), а затем использовать его для атаки на объекты, находящиеся за межсетевым экраном (со всем доступом и полномочиями, которыми наделен веб-сервер). В тестировании на проникновение она также известна как «поворот»: получение доступа к сетевому ресурсу, а затем использование его для получения дальнейшего доступа.

При этом данная атака также может быть использована для получения доступа к конфиденциальным данным или для вызова таких интернет-ресурсов, как API.

Десериализация

Сериализация – это перевод данных из памяти (объекта) в файл или поток для того, чтобы их можно было передавать или хранить. Десериализация – возвращение данных в исходное состояние (память или объект) после передачи данных или в случае их надобности. Чаще всего данный процесс осуществляется в XML, JSON и Java, однако существует несколько других ситуаций и технологий.

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

Самый простой способ избежать проблемы – не использовать эту функцию. Если ничего не сериализовать, то и десериализация не понадобится. Данная мысль может показаться упрощением, и так оно и есть. По возможности следует избегать любых потенциально рискованных ситуаций.

Если это невозможно, то вместо объектной сериализации данных следует использовать формат обработки данных (JSON, XML, YAML) для загрузки данных в граф объекта.

Если вам безоговорочно необходимо принять сериализованные объекты, они должны быть только из надежного источника и содержать лишь примитивные типы данных (типы, определенные как часть используемого языка программирования по умолчанию, например int и char).

Ниже перечислены некоторые меры предосторожности при работе с сериализованными объектами.

• Никогда не принимать сериализованный объект от ненадежного отправителя. Отправитель считается надежным, если он внесен в список одобренных. Никогда не принимать сериализованный объект от пользователя.

• Использовать защитную десериализацию с входным потоком объектов вместе со строгим утвержденным списком разрешенных классов.

• Десериализовывать только подписанные объекты и проверять контрольную сумму либо использовать HMAC с хешем SHA256.

• Принимать только примитивные (неизменяемые) типы данных.

На сайте OWASP.org описано еще несколько шагов безопасной обработки сериализованных объектов из ненадежных источников. Однако, поскольку обстановка постоянно меняется, они не будут указаны здесь.

Главное, что нужно запомнить, – при любой возможности избегайте сериализации и десериализации. Если необходимо принимать сериализованные объекты, они должны быть только из надежных источников. Если следовать этому совету невозможно, то необходимо проявлять крайнюю осторожность в работе с такими объектами.

ПРИМЕЧАНИЕ. Если говорить в общем, то при десериализации злоумышленник заменяет сериализованную информацию своей собственной, которая содержит атаку на веб-сервер или приложение.