<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 [**NFT esclusivi**](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.
Se sei interessato a una **carriera nell'hacking** e vuoi hackerare l'impossibile - **stiamo assumendo!** (_richiesta competenza fluente in polacco, scritta e parlata_).
Carriage Return (CR) e Line Feed (LF), collettivamente noti come CRLF, sono sequenze di caratteri speciali utilizzate nel protocollo HTTP per indicare la fine di una riga o l'inizio di una nuova. I server web e i browser utilizzano CRLF per distinguere tra gli header HTTP e il corpo di una risposta. Questi caratteri sono universalmente utilizzati nelle comunicazioni HTTP/1.1 tra vari tipi di server web, come Apache e Microsoft IIS.
L'iniezione CRLF comporta l'inserimento dei caratteri CR e LF in un input fornito dall'utente. Questa azione inganna il server, l'applicazione o l'utente facendo 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 divisione delle risposte HTTP e ad altre attività malevole.
Considera un file di log in un pannello di amministrazione che segue il formato: `IP - Ora - Percorso Visitato`. Una voce tipica potrebbe apparire come:
Un attaccante può sfruttare un'iniezione CRLF per manipolare questo registro. Iniettando caratteri CRLF nella richiesta HTTP, l'attaccante può alterare il flusso di output e creare voci di registro false. Ad esempio, una sequenza iniettata potrebbe trasformare la voce di registro in:
L'attaccante nasconde così le sue attività malevole facendo apparire come se il localhost (un'entità tipicamente fidata nell'ambiente del 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 è una vulnerabilità di sicurezza che si verifica quando un attaccante sfrutta la struttura delle risposte HTTP. Questa struttura separa gli header dal corpo utilizzando una sequenza di caratteri specifica, Carriage Return (CR) seguito da Line Feed (LF), collettivamente chiamata CRLF. Se un attaccante riesce a inserire una sequenza CRLF in un header di risposta, può manipolare efficacemente il contenuto della risposta successiva. Questo tipo di manipolazione può causare gravi problemi di sicurezza, in particolare Cross-site Scripting (XSS).
1. L'applicazione imposta un header personalizzato come questo: `X-Custom-Header: UserInput`
2. L'applicazione recupera il valore per `UserInput` da un parametro di query, ad esempio "user_input". In scenari privi di una corretta convalida e codifica dell'input, un attaccante può creare un payload che include la sequenza CRLF, seguita da un contenuto maligno.
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 URL-encoded di CRLFCRLF. Inganna il server facendogli inserire una sequenza CRLF, facendo sì che il server tratti la parte successiva come il corpo della risposta.
4. Il server riflette l'input dell'attaccante nell'header di risposta, portando a una struttura di risposta non intenzionale in cui lo script maligno viene interpretato dal browser come parte del corpo della risposta.
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** del server (esempio da [qui](https://hackerone.com/reports/192667)):
L'iniezione di intestazione HTTP, spesso sfruttata tramite l'iniezione di CRLF (Carriage Return and Line Feed), consente agli attaccanti di inserire intestazioni HTTP. Ciò può compromettere meccanismi di sicurezza come i filtri XSS (Cross-Site Scripting) o la SOP (Same-Origin Policy), portando potenzialmente a un accesso non autorizzato a dati sensibili, come i token CSRF, o alla manipolazione delle sessioni utente tramite l'inserimento di cookie.
Un attaccante può iniettare intestazioni HTTP per abilitare CORS (Cross-Origin Resource Sharing), eludendo le restrizioni imposte dalla SOP. Questa violazione consente a script provenienti da origini maligne di interagire con risorse provenienti da un'origine diversa, potenzialmente accedendo a dati protetti.
L'iniezione di CRLF può essere utilizzata per creare e iniettare una nuova richiesta HTTP. Un esempio notevole di ciò è la vulnerabilità nella classe `SoapClient` di PHP, specificamente nel parametro `user_agent`. Manipolando questo parametro, un attaccante può inserire intestazioni aggiuntive e contenuto del corpo, o addirittura iniettare completamente una nuova richiesta HTTP. Di seguito è riportato un esempio in PHP che dimostra questa forma di sfruttamento:
Per ulteriori informazioni su questa tecnica e potenziali problemi, [**controlla la fonte originale**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Successivamente, è possibile specificare una seconda richiesta. Questo scenario coinvolge tipicamente [HTTP request smuggling](http-request-smuggling/), una tecnica in cui gli header extra o gli elementi del corpo aggiunti dal server post-iniezione possono portare a varie vulnerabilità di sicurezza.
1.**Iniezione di prefisso maligno**: Questo metodo prevede l'inserimento di un prefisso maligno nella richiesta successiva dell'utente o nella cache web. Un esempio di ciò è:
2.**Creazione di un prefisso per l'iniezione nella coda di risposta**: Questo approccio prevede la creazione di un prefisso che, combinato con dati inutili alla fine, forma una seconda richiesta completa. Ciò può innescare l'iniezione nella coda di risposta. Un esempio è:
**Per tutte le informazioni complete leggi il**[ **documento originale**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
Se una piattaforma **prende dati da una richiesta HTTP e li utilizza senza sanificazione** per eseguire **richieste** a un server **memcache**, un attaccante potrebbe sfruttare questo comportamento per **iniettare nuovi comandi memcache**.
Ad esempio, nella vulnerabilità originale scoperta, le chiavi della cache venivano utilizzate per restituire l'indirizzo IP e la porta a cui un utente doveva connettersi, e gli attaccanti erano in grado di **iniettare comandi memcache** che avrebbero **avvelenato** la **cache per inviare i dettagli delle vittime** (compresi nomi utente e password) ai server degli attaccanti:
Inoltre, i ricercatori hanno scoperto che potevano desincronizzare le risposte di memcache per inviare agli utenti, di cui l'attaccante non conosceva l'email, l'indirizzo IP e le porte degli attaccanti:
Se non è possibile evitare l'inserimento diretto dell'input utente, assicurarsi di utilizzare una funzione dedicata alla codifica dei caratteri speciali come CR (Carriage Return) e LF (Line Feed). Questa pratica impedisce la possibilità di iniezione CRLF.
Aggiornare regolarmente il linguaggio di programmazione utilizzato nelle applicazioni web all'ultima versione. Optare per una versione che impedisca intrinsecamente l'iniezione dei caratteri CR e LF all'interno delle funzioni incaricate di impostare gli header HTTP.
Se sei interessato a una **carriera di hacking** e a violare l'invulnerabile - **stiamo assumendo!** (_richiesta competenza fluente in polacco, scritta e parlata_).
<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 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.
