Server Side Inclusion/Edge Side Inclusion Injection
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:
Überprüfen
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:
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:
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>
-DirektiveVars: Unterstützt die
<esi:vars>
-Direktive. Nützlich zum Umgehen von XSS-FilternCookie: 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
Umgehung des Client-XSS-Schutzes
Steal Cookie
Fernzugriff auf Cookies stehlen
Stehlen Sie das Cookie HTTP_ONLY mit XSS, indem Sie es in der Antwort reflektieren:
Private Local File
Verwechseln Sie dies nicht mit einer "Local File Inclusion":
CRLF
Open Redirect
Das Folgende wird einen Location
-Header zur Antwort hinzufügen
Header hinzufügen
Header in erzwungenem Request hinzufügen
Fügen Sie einen Header in die Antwort ein (nützlich, um "Content-Type: text/json" in einer Antwort mit XSS zu umgehen)
CRLF im Add-Header (CVE-2019-2438)
Akamai-Debug
Dies sendet Debug-Informationen, die in der Antwort enthalten sind:
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.
XSLT-Datei:
Check the XSLT-Seite:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)Referenzen
Brute-Force-Erkennungsliste
Last updated