CRLF è l’acronimo usato per riferirsi a Carriage Return (\r) Line Feed (\n). Come si può notare dai simboli tra parentesi, ” Ritorno a capo “si riferisce alla fine di una riga e” Avanzamento riga” si riferisce alla nuova riga. Quindi, sia CR che LF sono usati per indicare il punto finale di una linea. Quando un utente richiede contenuti su un sito web, il server restituisce il contenuto del sito Web insieme alle intestazioni HTTP. Le intestazioni e il contenuto sono separati da una combinazione definita di CR e LF. È a causa di CRLF che un server sa dove inizia o finisce una nuova intestazione. Una vulnerabilità di iniezione CRLF (Carriage Return Line Feed) è un tipo di iniezione lato server che si verifica quando un utente malintenzionato inserisce i caratteri CRLF in un campo di input per ingannare il server facendogli pensare che un oggetto è terminato e uno nuovo è iniziato. Ciò accade quando l’applicazione Web non disinfetta l’input dell’utente per i caratteri CRLF. Ha una valutazione di gravità media (P3 secondo il VRT di Bugcrowd).

CRLF Injection attack ha due casi d’uso più importanti:

• Log Splitting: L’attaccante inserisce un carattere di fine riga e una riga in più per falsificare le voci del file di registro al fine di ingannare gli amministratori di sistema nascondendo altri attacchi.
• Divisione della risposta HTTP: l’iniezione CRLF viene utilizzata per aggiungere intestazioni HTTP alla risposta HTTP e, ad esempio, eseguire un attacco XSS che porta alla divulgazione delle informazioni.

Esempio:

Una semplice richiesta GET può essere creata come segue:

GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1

Nota: %0d e %0a sono forme codificate rispettivamente di \r e \n. Se l’applicazione web è vulnerabile, un utente malintenzionato sarà in grado di impostare un cookie sul sito web.

Impatti di CRLF injection

CRLF Injection consente all’utente malintenzionato di impostare cookie falsi, rubare token CSRF, divulgare informazioni utente iniettando uno script (XSS) ed eseguire una serie di altri attacchi. Consente inoltre agli aggressori di disattivare& bypassare le misure di sicurezza come i filtri XSS& Same Origin Policy (SOP), rendendoli suscettibili ai seguenti attacchi:

1. XSS o Cross Site Scripting
XSS o Cross Site Scripting è una vulnerabilità di sicurezza che consente a un utente malintenzionato di iniettare codice JavaScript dannoso nell’applicazione web. Le seguenti richieste GET sono create in un tentativo di iniezione CRLF a catena con XSS.
Visualizzando un avviso contenente informazioni sensibili dell’utente

www.target.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

Disabilitando la protezione XSS

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2. Cookie Injection
HTTP Response Splitting consente a un utente malintenzionato di impostare cookie dannosi sul browser della vittima. Nella maggior parte dei casi, la seguente richiesta GET si tradurrà in un reindirizzamento 307, e quindi la vittima verrà reindirizzato a target.com & l’URL non conterrà il parametro Set-Cookie. In background, tuttavia, verrà impostato il cookie.

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. Attacchi di phishing
Un utente malintenzionato può impostare l’intestazione della posizione che reindirizza la vittima al sito web malvagio. Questo sito web può essere sviluppato per assomigliare al sito Web di destinazione e quando la vittima inserisce le proprie credenziali, verranno inviate all’attaccante. L’intestazione della posizione può essere impostata come:

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4. Fissazione della sessione
Simile all’attacco di iniezione di cookie, qui l’attaccante imposta l’ID di sessione di un utente su un particolare valore. Questo collegamento viene inviato alla vittima e quando la vittima accede utilizzando questa sessione, l’utente malintenzionato può anche accedere utilizzando lo stesso ID di sessione.

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. HTTP Header Injection
Un utente malintenzionato può sfruttare l’iniezione CRLF per iniettare intestazioni HTTP in un’applicazione al fine di sconfiggere i meccanismi di sicurezza come filtri XSS o la stessa-origine-politica.

www.target.com/%0d%0aHackersHeader:NewHeader

CORS (Cross-Origin Resource Sharing) attivazione di intestazioni possono essere iniettati & l’utente malintenzionato può utilizzare JavaScript per accedere a risorse sensibili che sono comunque protetto da SOP (same Origin Policy) che impedisce siti da origini diverse per accedere a vicenda.
6. Web Cache poisoning
Web-cache poisoning è una tecnica grazie alla quale un utente malintenzionato può servire contenuti avvelenati manipolando una cache web. Per sfruttare con successo questo problema, un utente malintenzionato dovrebbe avvelenare il proxy di caching del sito Web vulnerabile, i syndicator, le reti di distribuzione dei contenuti (CDN) o altri meccanismi di caching tra il client e il server. Dopo un avvelenamento della cache Web di successo, la vittima non avrà idea del contenuto dannoso che viene loro servito dalla cache. Di seguito è riportato un esempio di come un utente malintenzionato potrebbe potenzialmente sfruttare un’iniezione di intestazione host (utilizzando CRLF) avvelenando una web-cache.

Per la seguente richiesta:

$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com

Ci sarebbe la seguente risposta:

HTTP/1.1 200 OK

Casi d’uso vari:

1. Iniettare una falsa intestazione di risposta HTTP:

Content-Length: 10

Ora, il browser Web analizzerà solo i prossimi 10 byte.
2. Injecting a fake HTTP response header:

Content-Length: 0

Questa viene trattata come una risposta terminata & i browser web iniziano l’analisi di una nuova risposta.

Mitigazioni:

Uno sviluppatore dovrebbe tenere a mente le seguenti cose per prevenire l’iniezione di CRLF:

• Sanificazione dell’input dell’utente.
• Codifica CR & Caratteri LF (\r, \n) in modo che anche quando vengono forniti, non vengano riconosciuti dal server.
• Convalida l’input dell’utente prima che raggiungano le intestazioni di risposta (ad esempio utilizzando metodi come StringEscapeUtils.escapeJava()).
• Un’intestazione non necessaria dovrebbe essere disabilitata.
  La seguente tabella sottolinea la gravità dell’iniezione di CRLF in base a vari standard di settore: