Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**Bug bounty tip**: **iscriviti** a **Intigriti**, una premium **bug bounty platform creata da hacker, per hacker**! Unisciti a noi su [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) oggi, e inizia a guadagnare bounty fino a **$100,000**!
Carriage Return (CR) e Line Feed (LF), collettivamente noti come CRLF, sono sequenze di caratteri speciali utilizzate nel protocollo HTTP per denotare la fine di una riga o l'inizio di una nuova. I server web e i browser utilizzano CRLF per distinguere tra le intestazioni HTTP e il corpo di una risposta. Questi caratteri sono impiegati universalmente nelle comunicazioni HTTP/1.1 attraverso vari tipi di server web, come Apache e Microsoft IIS.
L'iniezione CRLF comporta l'inserimento di caratteri CR e LF nell'input fornito dall'utente. Questa azione inganna il server, l'applicazione o l'utente facendoli interpretare la sequenza iniettata come la fine di una risposta e l'inizio di un'altra. Sebbene questi caratteri non siano intrinsecamente dannosi, il loro uso improprio può portare a HTTP response splitting e ad altre attività malevole.
Un attaccante può sfruttare un'iniezione CRLF per manipolare questo log. Iniettando caratteri CRLF nella richiesta HTTP, l'attaccante può alterare il flusso di output e fabbricare voci di log. Ad esempio, una sequenza iniettata potrebbe trasformare la voce di log in:
L'attaccante quindi maschera le proprie attività malevole facendole apparire come se il localhost (un'entità tipicamente fidata all'interno dell'ambiente server) avesse eseguito le azioni. Il server interpreta la parte della query che inizia con `%0d%0a` come un singolo parametro, mentre il parametro `restrictedaction` viene analizzato come un altro input separato. La query manipolata imita efficacemente un comando amministrativo legittimo: `/index.php?page=home&restrictedaction=edit`
### HTTP Response Splitting
#### Descrizione
HTTP Response Splitting è una vulnerabilità di sicurezza che si verifica quando un attaccante sfrutta la struttura delle risposte HTTP. Questa struttura separa le intestazioni dal corpo utilizzando una sequenza di caratteri specifica, Carriage Return (CR) seguito da Line Feed (LF), collettivamente denominata CRLF. Se un attaccante riesce a inserire una sequenza CRLF in un'intestazione di risposta, può manipolare efficacemente il contenuto della risposta successiva. Questo tipo di manipolazione può portare a gravi problemi di sicurezza, in particolare Cross-site Scripting (XSS).
#### XSS attraverso HTTP Response Splitting
1. L'applicazione imposta un'intestazione personalizzata come questa: `X-Custom-Header: UserInput`
2. L'applicazione recupera il valore per `UserInput` da un parametro di query, diciamo "user\_input". In scenari privi di una corretta validazione e codifica dell'input, un attaccante può creare un payload che include la sequenza CRLF, seguita da contenuto malevolo.
3. Un attaccante crea un URL con un 'user\_input' appositamente creato: `?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>`
* In questo URL, `%0d%0a%0d%0a` è la forma codificata in URL di CRLFCRLF. Inganna il server facendogli inserire una sequenza CRLF, costringendo il server a trattare la parte successiva come il corpo della risposta.
4. Il server riflette l'input dell'attaccante nell'intestazione di risposta, portando a una struttura di risposta non intenzionata in cui lo script malevolo viene interpretato dal browser come parte del corpo della risposta.
#### Un esempio di HTTP Response Splitting che porta a un Redirect
Da [https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62](https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62)
Puoi inviare il payload **all'interno del percorso URL** per controllare la **risposta** dal server (esempio da [qui](https://hackerone.com/reports/192667)):
L'iniezione di header HTTP, spesso sfruttata attraverso l'iniezione CRLF (Carriage Return e Line Feed), consente agli attaccanti di inserire header HTTP. Questo può compromettere meccanismi di sicurezza come i filtri XSS (Cross-Site Scripting) o il SOP (Same-Origin Policy), portando potenzialmente ad accessi non autorizzati a dati sensibili, come i token CSRF, o alla manipolazione delle sessioni utente tramite l'inserimento di cookie.
Un attaccante può iniettare header HTTP per abilitare CORS (Cross-Origin Resource Sharing), eludendo le restrizioni imposte dal SOP. Questa violazione consente a script provenienti da origini malevole di interagire con risorse di un'origine diversa, accedendo potenzialmente a dati protetti.
L'iniezione CRLF può essere utilizzata per creare e iniettare una nuova richiesta HTTP. Un esempio notevole di questo è la vulnerabilità nella classe `SoapClient` di PHP, specificamente all'interno del parametro `user_agent`. Manipolando questo parametro, un attaccante può inserire header e contenuti del corpo aggiuntivi, o persino iniettare completamente una nuova richiesta HTTP. Di seguito è riportato un esempio PHP che dimostra questo sfruttamento:
Per ulteriori informazioni su questa tecnica e sui potenziali problemi [**controlla la fonte originale**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Dopo, può essere specificata una seconda richiesta. Questo scenario coinvolge tipicamente [HTTP request smuggling](http-request-smuggling/), una tecnica in cui intestazioni o elementi del corpo aggiunti dal server dopo l'iniezione possono portare a vari exploit di sicurezza.
1.**Iniezione di Prefisso Maligno**: Questo metodo implica il avvelenamento della richiesta del prossimo utente o di una cache web specificando un prefisso maligno. Un esempio di questo è:
2.**Creazione di un Prefisso per il Avvelenamento della Coda di Risposta**: Questo approccio implica la creazione di un prefisso che, quando combinato con spazzatura finale, forma una seconda richiesta completa. Questo può attivare l'avvelenamento della coda di risposta. Un esempio è:
Se una piattaforma sta **prendendo dati da una richiesta HTTP e utilizzandoli senza sanitizzarli** per effettuare **richieste** a un server **memcache**, un attaccante potrebbe abusare di questo comportamento per **iniettare nuovi comandi memcache**.
Ad esempio, nella vulnerabilità scoperta originariamente, le chiavi della cache venivano utilizzate per restituire l'IP e la porta a cui un utente dovrebbe connettersi, e gli attaccanti erano in grado di **iniettare comandi memcache** che avrebbero **avvelenato** la **cache per inviare i dettagli delle vittime** (inclusi nomi utente e password) ai server dell'attaccante:
Inoltre, i ricercatori hanno anche scoperto che potevano desincronizzare le risposte memcache per inviare l'IP e le porte degli attaccanti a utenti di cui l'attaccante non conosceva l'email:
1.**Evitare l'Input Diretto dell'Utente negli Header di Risposta:** L'approccio più sicuro è astenersi dall'incorporare input forniti dall'utente direttamente negli header di risposta.
2.**Codificare i Caratteri Speciali:** Se evitare l'input diretto dell'utente non è fattibile, assicurati di utilizzare una funzione dedicata alla codifica di caratteri speciali come CR (Carriage Return) e LF (Line Feed). Questa pratica previene la possibilità di iniezione CRLF.
3.**Aggiornare il Linguaggio di Programmazione:** Aggiorna regolarmente il linguaggio di programmazione utilizzato nelle tue applicazioni web all'ultima versione. Opta per una versione che di per sé non consenta l'iniezione di caratteri CR e LF all'interno delle funzioni incaricate di impostare gli header HTTP.
**Suggerimento per bug bounty**: **iscriviti** a **Intigriti**, una premium **bug bounty platform creata da hacker, per hacker**! Unisciti a noi su [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) oggi, e inizia a guadagnare ricompense fino a **$100,000**!
Impara e pratica Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Impara e pratica Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos su github.