Эта статья объяснит вам основы уязвимостей XXE. Когда сервер анализирует XML-данные, предоставленные пользователем, существует риск уязвимостей XXE. Эти уязвимости обычно используют внешние объекты для раскрытия конфиденциальной информации, хранящейся на сервере. Это возможно благодаря функции, известной как внешние объекты XML. Это тип настраиваемой XML-сущности, которая может загружать значения вне документа, в котором они определены. Это означает, что злоумышленник может объявить путь к файлу или URL-адресу, и сервер попытается получить эти данные. Это, в свою очередь, позволяет злоумышленнику раскрыть содержимое целевого файла или URL-адреса.
В этой статье мы рассмотрим четыре атаки на основе XXE:
1. XXE через сообщения формы для извлечения файлов.
2. XXE через сообщения формы для выполнения атак SSRF.
3. XXE через тег XInclude.
4. Загрузка файлов XXE через SVG.
Чтобы продемонстрировать эти типы атак, я собираюсь использовать лабораторные работы, доступные по адресу https://portswigger.net/web-security/xxe. Доступ к этим лабораториям можно получить бесплатно после регистрации учетной записи. Я также буду использовать инструмент Burp Suite от portswigger, чтобы продемонстрировать фальсификацию пакетов. Видео в начале статьи покажет визуальное пошаговое руководство по этим лабораторным работам, поэтому оно будет полезно, если вы хотите увидеть визуальное пошаговое руководство.
XXE для получения файлов
Для начала мы рассмотрим использование XXE для доступа к файлу / etc / passwd с целевого сервера. Когда мы зайдем на веб-страницу лаборатории, мы увидим несколько элементов, детали которых сможем просмотреть.
Если мы введем какой-либо товар, появится область, где мы можем проверить наличие товара в данном магазине. Если мы воспользуемся Burp Suite для перехвата пакетов, мы увидим, что складской запрос отправляется в формате XML.
Если мы переместим этот пакет в ретранслятор с помощью Action- ›Send To Repeater, мы сможем поэкспериментировать с этим пакетом, чтобы попробовать разные входы, чтобы найти тот, который работает. Формат XML легко увидеть на вкладке XML на пакете.
Отсюда мы можем изменить данные XML, чтобы добавить в XXE, чтобы запросить файл, который мы хотим нацелить. Сначала я покажу, что работает измененный ввод, а затем объясню, как и почему он работает.
В содержимом строки 2 мы определяем внешнюю сущность, на которую хотим сослаться. В этой строке xxe - это имя переменной, в которой хранится внешний объект. Нам нужен системный ресурс, путь к которому мы указываем в виде файла. Как только это определено, мы заменяем параметр productid объявленной нами внешней сущностью. Отсюда мы можем отправить запрос и получить следующие результаты.
Что происходит, так это то, что XML-файл заменяет предыдущий productid содержимым внешнего объекта, которым является файл / etc / passwd. Затем он запрашивает у сервера идентификатор продукта, равный содержимому файла / etc / passwd. Поскольку это недействительный идентификатор продукта, он возвращает сообщение об ошибке. В сообщении об ошибке указано, что идентификатор продукта недействителен, и выводится идентификатор продукта, который он пытался использовать. Поскольку идентификатор продукта был содержимым файла / etc / passwd, содержимое файла выводится на экран.
Структура атак на основе XXE обычно соответствует этому точному формату с некоторыми простыми вариациями для соответствия сценарию. Общие шаги для успешного проведения атаки XXE:
1. Определите, какие XML-данные отправляются на сервер.
2. Определите, какой параметр анализируется сервером.
3. Определите внешнюю сущность, указывающую на целевой файл или URL.
4. Установите параметр, анализируемый сервером, равным внешнему объекту.
XXE для выполнения атак SSRF
Атака SSRF позволяет злоумышленнику выполнить подделку запроса на стороне сервера. По сути, это означает, что злоумышленник может отправлять HTTP-запросы на любой URL-адрес, к которому имеет доступ сервер. Это означает, что они могут получить доступ к URL-адресам, к которым у них обычно нет разрешения, что потенциально может привести к утечке данных.
Рассмотрим тот же пример, что и предыдущий, когда мы отправляем XML для получения запасов магазина, вместо того, чтобы указывать файлы для извлечения, мы можем вместо этого указать URL-адреса. Запрос будет выглядеть следующим образом.
На самом деле единственное, что изменяется в запросе, - это то, что мы указываем URL-адрес вместо файла в системе. Когда URL-запрос будет возвращен, мы увидим, что в нем мало информации.
Это показывает нам следующий путь в URL-адресе, поэтому теперь мы можем попробовать запросить http://169.254.169.254/latest
Мы можем продолжать повторять это, пока не дойдем до данных безопасности, хранящихся на сервере.
Это покажет содержимое URL-адреса.
Из этого мы видим, что атаки XXE позволяют нам не только раскрывать файлы, но и URL-адреса, доступные серверу. Это означает, что почти все данные, доступные серверу, подвергаются риску компрометации, если присутствуют уязвимости XXE. Учитывая, что это так, важно понимать еще несколько неясных способов создания условий атаки XXE.
XXE через тег XInclude
Часто злоумышленник не имеет полного контроля над данными XML, но имеет контроль над вводом, переданным в данные. В этих случаях они не могут внедрить сущность перед параметрами XML, что делает невозможным проведение атак XXE. Однако часто можно провести атаку XXE, используя только один параметр, используя функцию XInclude XML.
XInclude можно рассматривать как способ включения другого XML-документа в существующий. Используя эту функцию, мы можем включить компонент XML, который определяет нашу внешнюю сущность, и использовать его для утечки данных с сервера. В этой ситуации данные, отправленные от клиента, включают только параметры, необходимые для добавления в XML.
Чтобы настроить XInclude, нам нужно ввести данные в параметр идентификатора продукта. Полезная нагрузка будет выглядеть, как показано ниже.
Без всей кодировки полезная нагрузка:
<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>
Начнем с демонстрации синтаксическому анализатору XML, что мы определяем XInclude. Отсюда мы настраиваем include, используя xi: include, предоставляя ему текст. Текст представляет собой href, указывающий на файл или URL-адрес, из которого мы хотим получить информацию. После запуска идентификатору продукта присваивается XInclude, который преобразуется в файл / etc / passwd. Как и раньше, он пытается разрешить файл, использовать его в качестве идентификатора продукта и возвращает ошибку, в которой говорится, что идентификатор продукта недействителен. В ошибке отображается содержимое файла.
Использование XXE с помощью файлов SVG
Важно отметить, что не все атаки XXE полагаются на базовый XML. XXE также можно найти в форматах файлов на основе XML, таких как файлы SVG. В этом примере мы рассмотрим, как можно получить утечку данных из файла с помощью файла SVG.
В этом примере у нас есть блог, в котором мы можем публиковать комментарии и загружать собственный аватар вместе с нашим комментарием. Аватар может быть в любом формате файла, включая файлы SVG.
Файлы SVG форматируются и часто анализируются так же, как обычный файл XML. Благодаря этому мы можем добавить код XXE так же, как и в любой другой пакет на основе XML. Следующий файл SVG может распечатать содержимое файла / etc / hostname в изображении аватара.
Мы начинаем очень похоже на другие примеры XXE, однако способ получения содержимого файла для вывода отличается. Строки 3 и 4 являются стандартными для большинства файлов SVG, а строка 5 - это то место, где мы фактически печатаем контент. В этой строке мы указываем текстовый элемент с размером шрифта, а также его местоположением. В качестве содержимого файла укажите переменную xxe, в которой хранится содержимое внешнего объекта / etc / hostname. Когда мы загружаем этот файл, полученное изображение имеет текст, содержащий содержимое файла / etc / hostname.
Это демонстрирует пример, в котором мы можем управлять атакой XXE без использования традиционного файла XXE или полезной нагрузки. Такие типы файлов, как SVG и любые другие, использующие формат XML, могут быть уязвимы для этого типа атак, поэтому важно обеспечить их безопасный синтаксический анализ.
Снижение риска атак XXE
Часто администраторы пытаются использовать WAF для предотвращения XXE, однако их обычно довольно легко обойти. Использование кодирования, такого как UTF-32, с шифрованием, как правило, может снизить видимость трафика WAF, что означает, что вы можете проскользнуть мимо полезной нагрузки, не будучи обнаруженным. В дополнение к этому, WAF, как правило, влияют на производительность, поэтому их использование может быть неоптимальным для вашего приложения.
Отключение пользовательских определений документов (DTD), если они не требуются, обычно является предпочтительным решением для предотвращения атак XXE. У каждого языка есть свой способ сделать это, поэтому вам нужно будет провести некоторое исследование, чтобы определить, как отключить настройку в соответствующем парсере / языке.
Благодаря этой статье вы должны научиться тестировать и находить уязвимости XXE в своих веб-приложениях.
