Kraken
  • 🐙Привет!
    • 👋Добро пожаловать!
  • ✏️Крупицы знаний
    • 🌚Общие статьи
      • Как установить Kali Linux
      • Как поставить виртуальную Kali Linux
      • Что такое CVE
      • Обзор популярных алгоритмов хеширования
      • Модель OSI
      • Какие есть алгоритмы шифрования
      • Что такое TCP/IP
      • HSTS
      • Что такое хеширование и как его используют в ИБ
      • Скрипт для проверки данных SSL-сертификата
      • Шифруем файлы на Kali Linux с помощью OpenSSL
      • Как работает WPA2
      • О протоколе FTP
      • Что такое CVSS
      • Что такое политика одного источника (SOP)
      • О Cross-Origin Resource Sharing (CORS)
      • О Content Security Policy (CSP)
      • Что такое Bash
      • Веб-сокеты
      • MITRE ATT&CK
      • Начало в OSINT
      • Особенности и подходы к тестированию мобильных приложений
      • Что такое REST
      • Что такое API
      • Сравнение безопасности среды iOS и Android
      • CSS в ИБ
    • 🎪Карьера
      • Какие бывают роли у пентестеров и в чем их смысл
      • Какие есть виды пентеста
      • Что входит в пентест
      • Какие есть области знаний в веб-пентесте
      • Главные ошибки новичков в ИБ
    • 😰Уязвимости
      • Об атаке Pastejaking
      • Об уязвимости KRACK
      • Об уязвимости Regex DoS
      • Об атаке MITM
      • Что такое уязвимость нулевого дня
      • Атака на протокол STP
      • Защита протокола STP
      • Clickjacking
      • База при атаке на Wi-Fi
      • Атаки по сторонним каналам
      • DNS ребайндинг
    • ⚙️Инструменты
      • Лучшие сканеры открытых портов и инструменты проверки портов
      • Что такое OWASP ZAP и как он помогает защитить приложения?
      • О фреймворке WiFi Exploitation Framework (WEF)
      • WeBaCoo — поддерживаем доступ к взломанному веб-серверу
      • Socialscan — проверяем использование электронной почты и имен пользователей в соцсетях
      • Обзор инструментов Red Team
      • 11 инструментов для сканирования уязвимостей
      • Подборка инструментов для автоматизации атак на JWT
      • О Bulk_Extractor
      • О Unicornscan
      • О Maryam
      • О Picocrypt, утилите для шифрования данных
      • Анализируем трафик с ZUI (Zed User Interface)
      • Об инструменте SkipFish
      • Как получить уведомления на почту о входе по SSH
      • О сканере OpenSCAP
      • О Censys — инструменте для поиска уязвимых поддоменов
      • О Scanless — инструменте для анонимного сканирования открытых портов
      • О SearchSploit — инструменте для поиска эксплойтов
      • Выбираем менеджер паролей
      • О Maltego
      • Устанавливаем и используем Snyk CLI в Windows
      • Проверяем безопасность Docker-образов с помощью Trivy
      • Об инструменте SpiderFoot
      • Сканируем сети с помощью скриптов Bash
      • О фреймворке Volatility на Windows
      • Определяем тип WAF с помощью WafW00f
      • Об инструменте ReNgine
      • О Foremost — инструменте для восстановления данных
      • Chisel — инструмент для проброса портов
      • O Yersinia
      • Об Acunetix
      • O Netcat
      • O Samba
      • O John the Ripper
      • О Common User Passwords Profiler (CUPP)
      • О RainbowCrack
      • Shodan
      • MobSF
      • Netsparker
      • Fortify
      • Veracode
      • Rapid7 InsightVM
      • Aircrack-ng
  • 🛠️ИНСТРУМЕНТЫ
    • ⌨️Беспроводные атаки
      • Aircrack-Ng
    • 🔑Атаки на пароли
      • Crunch
      • John
      • CUPP
      • Hashcat
      • Hydra
    • 👁️Сбор Информации
      • Masscan
      • Dnsenum
      • Parsero
      • Nmap
  • 👨‍💻Пентест
    • Методология
    • 🖥️Аппаратный/Физический доступ
      • Физические атаки
      • Побег из КИОСКа
  • 👾MITRE
    • 🗺️Тактики
      • 🏢Предприятия
        • Разведка
      • 📱Мобильные устройства
      • 🏭ICS
    • 💀CTI
      • ☠️Группы
        • admin@338
        • Ajax Security Team
        • ALLANITE
        • Andariel
  • 📟Справочник по безопасной разработке
    • 👨‍🔬CLIENT SIDE
      • Cross-Site Scripting [XSS]
      • Cross-Site Request Forgery [CSRF]
      • Clickjacking
      • Open Redirects
    • 🖥️SERVER SIDE
      • SQL Injections [SQLi]
      • XML External Entity Injection [XXE]
      • OS Command Injection [Command Execution]
      • File Upload
      • Server-Side Request Forgery [SSRF]
      • Host Header Injection
      • Аутентификация
      • Directory Traversal
      • Template Injection [SSTI]
    • API
  • 🐝OWASP
    • Cross Site Scripting (XSS)
Powered by GitBook
On this page
  • 1. Введение:
  • 2. Типичный уязвимый код:
  • 3. Смягчение последствий:
  • 2.1. Отключение встроенного DTD:
  • 2.2. Следуйте принципу наименьших привилегий:
  • 3. Выводы:
  1. Справочник по безопасной разработке
  2. SERVER SIDE

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

📟
🖥️