XML External Entity Injection [XXE]

1. Введение:

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

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

2. Типичный уязвимый код:

var parserOptions = {
    noblanks: true,
    noent: true,
    nocdata: true
};

try {
    var doc = libxml.parseXmlString(data, parserOptions);
} catch (e) {
    return Promise.reject('XML parse error');
}

from django.http import HttpResponse
from lxml import etree

def authenticate(content):
    parser = etree.XMLParser(resolve_entities=True)
    try:
        document = etree.fromstring(content, parser)
    except etree.XMLSyntaxError:
        return None

class Loader
{
    /**
    * @param string $path
    * @return DOMDocument
    */
    public function load($path)
    {
         $dom = new DOMDocument();
         $dom->loadXML(file_get_contents($path));
         return $dom;
    }
}

Атака XXE работает, используя возможности XML, а именно XML eXternal Entities (XXE), которые позволяют загружать внешние XML-ресурсы в XML-документ.

Передав XML-файл, определяющий внешнюю сущность, с URI file://, злоумышленник может эффективно обмануть парсер SAX (Simple API parser for XML) приложения и заставить его прочитать содержимое произвольного файла (файлов), находящегося в файловой системе сервера.

Наконец, мы используем XML-декларацию ENTITY для загрузки дополнительных данных с внешнего ресурса. Синтаксис объявления ENTITY таков: ENTITY name SYSTEM URI, где URI - это полный путь к удаленному URL или локальному файлу. В нашем примере мы определяем тег ENTITY для загрузки содержимого файла "file:///etc/passwd".

Это пример того, как может выглядеть XML-файл "полезной нагрузки".

<!DOCTYPE foo [<!ELEMENT foo ANY >
<!ENTITY bar SYSTEM "file:///etc/passwd" >]>
<?xml version="1.0" encoding="UTF-8"?>

<trades>
    <metadata>
        <name>Apple Inc</name>
        <stock>AAPL</stock>
        <trader>
            <foo>&bar;</foo>
            <name>B.Bobi</name>
        </trader>
        <units>1500</units>
        <price>130</price>
        <name>Google</name>
        <stock>GOOGL</stock>
        <trader>
            <name>B.Bobi</name>
        </trader>
        <units>1500</units>
        <price>130</price>
    </metadata>
</trades>

Когда этот XML-документ обрабатывается уязвимым парсером, таким как представленный выше, все экземпляры &bar; будут заменены содержимым файла /etc/passwd.

Проще говоря, XML-парсер был обманут, чтобы получить доступ к ресурсу, который разработчики приложения не планировали делать доступным, в данном случае к файлу в локальной файловой системе удаленного сервера. Благодаря этой уязвимости можно было получить любой файл на удаленном сервере (точнее, любой файл, к которому веб-сервер имеет доступ на чтение).

К сожалению, парсер SAX не был настроен на запрет загрузки внешних сущностей (деклараций DOCTYPE), которые, будучи указанными в нашем модифицированном файле payload.xml, могут быть использованы злоумышленником для чтения произвольных системных файлов на удаленном сервере.

Поскольку пользовательский XML-ввод поступает из "недоверенного источника" (а именно, от клиента), очень трудно должным образом проверить XML-документ, чтобы предотвратить этот тип атаки.

3. Смягчение последствий:

2.1. Отключение встроенного DTD:

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

Из-за того, что существует множество движков для разбора XML, каждый из них имеет свой собственный механизм отключения встроенных DTD для предотвращения XXE. Возможно, вам придется поискать в документации к вашему XML-парсеру, как именно "отключить inline DTD".

Вот несколько примеров того, как можно отключить парсинг встроенного DTD.

var parserOptions = {
    noblanks: true,
    noent: false, // doesn't allow DOCTYPE declarations
    nocdata: true
};

try {
    var doc = libxml.parseXmlString(data, parserOptions);
} catch (e) {
    return Promise.reject('XML parse error');
}

from django.http import HttpResponse
from lxml import etree

def authenticate(content):
    parser = etree.XMLParser(resolve_entities=False)
    # False -> doesn't allow DOCTYPE declarations
    try:
        document = etree.fromstring(content, parser)
    except etree.XMLSyntaxError:
        return None

class Loader
{
    /**
    * @param string $path
    * @return DOMDocument
    */
    public function load($path)
    {
        $old = libxml_disable_entity_loader(true);
        // disable entity loader -> does not alow DOCTYPE declarations
        $dom = new DOMDocument();
        $dom->loadXML(file_get_contents($path));
        libxml_disable_entity_loader($old);
        return $dom;
    }
}

2.2. Следуйте принципу наименьших привилегий:

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

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

3. Выводы:

Общеизвестно, что DTD - это устаревшая технология, поэтому разрешение на использование встроенных DTD - это ВСЕГДА НЕПРАВИЛЬНАЯ ИДЕЯ! Современные парсеры XML по умолчанию защищены от атак, и поэтому использование таких фреймворков или парсеров означает, что вы уже защищены от атак.

Last updated 1 year ago

hashtag1. Введение:

hashtag2. Типичный уязвимый код:

hashtag3. Смягчение последствий:

hashtag2.1. Отключение встроенного DTD:

hashtag2.2. Следуйте принципу наименьших привилегий:

hashtag3. Выводы: