<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata su 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.
Usa [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) per creare e **automatizzare flussi di lavoro** con gli strumenti comunitari più avanzati al mondo.\
> * Nel **cache poisoning**, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti dannosi nella cache e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
> * Nella **cache deception**, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti sensibili appartenenti a un altro utente nella cache e l'attaccante recupera poi questi contenuti dalla cache.
Il cache poisoning mira a manipolare la cache lato client per costringere i client a caricare risorse inaspettate, parziali o sotto il controllo di un attaccante. L'entità dell'impatto dipende dalla popolarità della pagina interessata, poiché la risposta contaminata viene servita esclusivamente agli utenti che visitano la pagina durante il periodo di contaminazione della cache.
1.**Identificazione degli input non chiave**: Si tratta di parametri che, sebbene non siano necessari per memorizzare una richiesta nella cache, possono modificare la risposta restituita dal server. L'identificazione di questi input è fondamentale poiché possono essere sfruttati per manipolare la cache.
2.**Sfruttamento degli input non chiave**: Dopo aver identificato gli input non chiave, il passo successivo consiste nel capire come sfruttare questi parametri per modificare la risposta del server in modo vantaggioso per l'attaccante.
3.**Garantire che la risposta manipolata sia memorizzata nella cache**: L'ultimo passaggio consiste nel garantire che la risposta manipolata sia memorizzata nella cache. In questo modo, ogni utente che accede alla pagina interessata mentre la cache è contaminata riceverà la risposta alterata.
Di solito, quando una risposta viene **memorizzata nella cache**, ci sarà un **header che lo indica**, puoi verificare a quali header dovresti prestare attenzione in questo post: [**Header di cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Se pensi che la risposta venga memorizzata nella cache, puoi provare a **inviare richieste con un header errato**, che dovrebbe ottenere una **risposta con codice di stato 400**. Quindi prova ad accedere normalmente alla richiesta e se la **risposta è un codice di stato 400**, sai che è vulnerabile (e potresti persino eseguire un DoS).\
Un header configurato in modo errato potrebbe essere semplicemente `\:` come header.\
Nota che a volte questi tipi di codici di stato non vengono memorizzati nella cache, quindi questo test sarà inutile.
Puoi utilizzare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) per **forzare i parametri e gli header** che potrebbero **modificare la risposta della pagina**. Ad esempio, una pagina potrebbe utilizzare l'header `X-Forwarded-For` per indicare al client di caricare lo script da lì:
Con il parametro/header identificato, controlla come viene **sanificato** e **dove** viene **riflesso** o influisce sulla risposta dall'header. Puoi sfruttarlo in qualche modo (eseguire un XSS o caricare un codice JS controllato da te? Eseguire un DoS?...)
Una volta **identificata** la **pagina** che può essere sfruttata, quale **parametro**/**header** utilizzare e **come** sfruttarlo, devi ottenere la pagina memorizzata nella cache. A seconda della risorsa che stai cercando di ottenere nella cache, potrebbe richiedere del tempo, potresti dover provare per diversi secondi.\
L'header **`X-Cache`** nella risposta può essere molto utile in quanto potrebbe avere il valore **`miss`** quando la richiesta non è stata memorizzata nella cache e il valore **`hit`** quando è memorizzata nella cache.\
L'header **`Cache-Control`** è interessante anche per sapere se una risorsa viene memorizzata nella cache e quando verrà memorizzata nuovamente: `Cache-Control: public, max-age=1800`\
Un altro header interessante è **`Vary`**. Questo header viene spesso utilizzato per **indicare ulteriori header** che vengono considerati **parte della chiave di cache** anche se di solito non sono chiave. Pertanto, se l'utente conosce l'`User-Agent` della vittima che sta mirando, può corrompere la cache per gli utenti che utilizzano quel determinato `User-Agent`.\
Un altro header correlato alla cache è **`Age`**. Definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy.
Quando si memorizza una richiesta nella cache, **fai attenzione agli header che utilizzi** perché alcuni di essi potrebbero essere utilizzati in modo **inaspettato** come **chiave** e la **vittima dovrà utilizzare lo stesso header**. Testa sempre un Cache Poisoning con **browser diversi** per verificare se funziona.
I cookie potrebbero anche essere riflessi nella risposta di una pagina. Se puoi abusarne per causare ad esempio un XSS, potresti essere in grado di sfruttare l'XSS su diversi client che caricano la risposta della cache malevola.
### Utilizzo di più intestazioni per sfruttare le vulnerabilità di avvelenamento della cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
A volte sarà necessario **sfruttare diversi input non chiave** per poter abusare della cache. Ad esempio, potresti trovare un **reindirizzamento aperto** se imposti `X-Forwarded-Host` su un dominio controllato da te e `X-Forwarded-Scheme` su `http`. **Se** il **server** sta **inoltrando** tutte le richieste **HTTP** a **HTTPS** e utilizza l'intestazione `X-Forwarded-Scheme` come nome di dominio per il reindirizzamento. Puoi controllare dove la pagina viene puntata dal reindirizzamento.
Se hai scoperto che l'header **`X-Host`** 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 l'User-Agent della vittima e avvelenare la cache utilizzando quel user agent:
Scopri qui come eseguire [attacchi di Avvelenamento della Cache sfruttando l'HTTP Request Smuggling](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
Lo [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere utilizzato per testare automaticamente l'avvelenamento della cache web. Supporta molte tecniche diverse ed è altamente personalizzabile.
Utilizza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) per creare e automatizzare facilmente flussi di lavoro supportati dagli strumenti comunitari più avanzati al mondo.\
ATS inoltrava il frammento all'interno dell'URL senza rimuoverlo e generava la chiave della cache utilizzando solo l'host, il percorso e la query (ignorando il frammento). Quindi la richiesta `/#/../?r=javascript:alert(1)` veniva inviata al backend come `/#/../?r=javascript:alert(1)` e la chiave della cache non conteneva il payload al suo interno, solo l'host, il percorso e la query.
L'invio di un valore errato nell'intestazione content-type provocava una risposta in cache 405. La chiave della cache conteneva il cookie, quindi era possibile attaccare solo gli utenti non autenticati.
GitLab utilizza i bucket GCP per archiviare 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 restituendo un corpo di risposta vuoto. Poteva anche supportare il metodo `PURGE`.
Nelle applicazioni Ruby on Rails, spesso viene utilizzato il middleware Rack. Lo scopo del codice Rack è quello di 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, creando un rischio per la sicurezza.
In passato, Cloudflare memorizzava in cache le risposte 403. Tentare di accedere a S3 o Azure Storage Blobs con intestazioni di autorizzazione errate avrebbe comportato una risposta 403 che veniva memorizzata nella cache. Anche se Cloudflare ha smesso di memorizzare nella cache le risposte 403, questo comportamento potrebbe essere ancora presente in altri servizi proxy.
Le cache spesso includono specifici parametri GET nella chiave della cache. Ad esempio, Varnish di Fastly memorizzava il parametro `size` nelle richieste. Tuttavia, se veniva inviata anche una versione URL-encoded del parametro (ad esempio, `siz%65`) con un valore errato, la chiave della cache veniva costruita utilizzando il parametro `size` corretto. Tuttavia, il backend avrebbe elaborato il valore nel parametro URL-encoded. L'URL-encoding del secondo parametro `size` portava alla sua esclusione dalla cache ma alla sua utilizzazione da parte del backend. Assegnare un valore di 0 a questo parametro risultava in un errore 400 Bad Request memorizzabile nella cache.
Alcuni sviluppatori bloccano le richieste con user-agent corrispondenti a strumenti ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come l'avvelenamento della cache e il DoS.
L'[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi delle intestazioni. Le intestazioni che contengono caratteri al di fuori dell'intervallo specificato **tchar** dovrebbero idealmente generare una risposta 400 Bad Request. Nella pratica, i server non sempre si attengono a questo standard. Un esempio notevole è Akamai, che inoltra intestazioni con caratteri non validi e memorizza qualsiasi errore 400, purché l'intestazione `cache-control` non sia presente. È stato identificato un pattern sfruttabile in cui l'invio di un'intestazione con un carattere non valido, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
Prima di tutto, nota che le **estensioni** come `.css`, `.js`, `.png`, ecc. sono di solito **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.
Un altro esempio molto chiaro può essere trovato in questo articolo: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Nell'esempio, viene spiegato che se carichi una pagina inesistente come _http://www.example.com/home.php/non-existent.css_, verrà restituito il contenuto di _http://www.example.com/home.php_ (**con le informazioni sensibili dell'utente**) e il server della cache salverà il risultato.\
Quindi, l'**attaccante** può accedere a _http://www.example.com/home.php/non-existent.css_ nel proprio browser e osservare le **informazioni confidenziali** degli utenti che hanno accesso in precedenza.
Nota che il **proxy della cache** dovrebbe essere **configurato** per **memorizzare** i file **in base all'estensione** del file (_.css_) e non in base al tipo di contenuto. 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_).
Scopri qui come eseguire [attacchi di Inganno della
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI 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 [**NFT**](https://opensea.io/collection/the-peass-family) esclusivi
* **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 repository github di** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
