Che cos’è CRLF?

Quando un browser invia una richiesta a un server Web, il server Web risponde con una risposta contenente sia le intestazioni di risposta HTTP che il contenuto effettivo del sito Web, ovvero il corpo della risposta. Le intestazioni HTTP e la risposta HTML (il contenuto del sito web) sono separate da una combinazione specifica di caratteri speciali, ovvero un ritorno a capo e un feed di riga. In breve sono anche conosciuti come CRLF.

Il server Web utilizza il CRLF per capire quando inizia una nuova intestazione HTTP e ne termina un’altra. Il CRLF può anche dire a un’applicazione Web o a un utente che una nuova riga inizia in un file o in un blocco di testo. I caratteri CRLF sono un messaggio HTTP / 1.1 standard, quindi viene utilizzato da qualsiasi tipo di server Web, inclusi Apache, Microsoft IIS e tutti gli altri.

Qual è la vulnerabilità CRLF Injection?

In un attacco di vulnerabilità CRLF injection l’attaccante inserisce sia il ritorno a capo che i caratteri di avanzamento riga nell’input dell’utente per ingannare il server, l’applicazione Web o l’utente a pensare che un oggetto è terminato e un altro è iniziato. In quanto tali le sequenze CRLF non sono caratteri dannosi, tuttavia possono essere utilizzate per scopi dannosi,per la suddivisione della risposta HTTP, ecc.

Iniezione CRLF nelle applicazioni web

Nelle applicazioni Web un’iniezione CRLF può avere impatti gravi, a seconda di ciò che l’applicazione fa con singoli elementi. Gli impatti possono variare dalla divulgazione delle informazioni all’esecuzione del codice, una vulnerabilità di sicurezza delle applicazioni Web impatto diretto. In effetti un attacco di iniezione CRLF può avere ripercussioni molto gravi su un’applicazione web, anche se non è mai stata elencata nella lista OWASP Top 10. Ad esempio, è anche possibile manipolare i file di registro in un pannello di amministrazione come spiegato nell’esempio seguente.

Un esempio di iniezione CRLF in un file di log

Immagina un file di log in un pannello di amministrazione con il pattern di flusso di output del percorso IP – Time – Visited, come il seguente:

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

Se un utente malintenzionato è in grado di iniettare i caratteri CRLF nella richiesta HTTP è in grado di modificare il flusso di output e falsificare le voci di registro. Può cambiare la risposta dall’applicazione webs in qualcosa di simile al seguente:

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

%0d e %0a sono le forme codificate url di CR e LF. Pertanto le voci di registro sarebbero simili a queste dopo che l’attaccante ha inserito quei caratteri e l’applicazione lo visualizza:

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

Quindi sfruttando una vulnerabilità CRLF injection l’attaccante può falsificare le voci nel file di log per offuscare le proprie azioni dannose. L’attaccante sta letteralmente facendo il dirottamento della pagina e modificando la risposta. Ad esempio, immagina uno scenario in cui l’attaccante ha la password di amministratore ed ha eseguito il parametro restrictedaction, che può essere utilizzato solo da un amministratore.

Il problema è che se l’amministratore nota che un IP sconosciuto ha utilizzato il parametro restrictedaction, noterà che qualcosa non va. Tuttavia, poiché ora sembra che il comando sia stato emesso dal localhost (e quindi probabilmente da qualcuno che ha accesso al server, come un amministratore) non sembra sospetto.

L’intera parte della query che inizia con %0d%0a verrà gestita dal server come un unico parametro. Dopodiché c’è un altro & con il parametro restrictedactionche verrà analizzato dal server come un altro parametro. In effetti questa sarebbe la stessa query di:

/index.php?page=home&restrictedaction=edit

Divisione della risposta HTTP

Descrizione

Poiché l’intestazione di una risposta HTTP e il suo corpo sono separati da caratteri CRLF, un utente malintenzionato può provare a iniettarli. Una combinazione di CRLFCRLF dirà al browser che l’intestazione termina e inizia il corpo. Ciò significa che ora è in grado di scrivere dati all’interno del corpo di risposta in cui è memorizzato il codice html. Questo può portare a una vulnerabilità Cross-site Scripting.

Un esempio di suddivisione della risposta HTTP che porta a XSS

Immagina un’applicazione che imposta un’intestazione personalizzata, ad esempio:

X-Your-Name: Bob

Il valore dell’intestazione viene impostato tramite un parametro get chiamato “nome”. Se non è presente alcuna codifica URL e il valore viene riflesso direttamente all’interno dell’intestazione, potrebbe essere possibile per un utente malintenzionato inserire la combinazione di CRLFCRLF sopra menzionata per dire al browser che inizia il corpo della richiesta. In questo modo è in grado di inserire dati come il payload XSS, ad esempio:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

Quanto sopra mostrerà una finestra di avviso nel contesto del dominio attaccato.

HTTP Header Injection

Description

Sfruttando un’iniezione CRLF un utente malintenzionato può anche inserire intestazioni HTTP che potrebbero essere utilizzate per sconfiggere i meccanismi di sicurezza come il filtro XSS di un browser o la politica same-origin -. Ciò consente all’utente malintenzionato di ottenere informazioni sensibili come i token CSRF. Può anche impostare cookie che potrebbero essere sfruttati registrando la vittima nell’account dell’attaccante o sfruttando vulnerabilità cross-site scripting (XSS) altrimenti non sfruttabili.

Un esempio di Intestazione HTTP Iniezione per estrarre dati sensibili

Se un utente malintenzionato è in grado di iniettare le intestazioni HTTP attivare CORS (Cross-Origin Resource Sharing), è possibile utilizzare javascript per accedere a risorse altrimenti protetti da SOP (same Origin Policy) che impedisce siti da origini diverse per accedere a vicenda.

Impatti della vulnerabilità CRLF injection

L’impatto delle iniezioni CRLF varia e include anche tutti gli impatti dello scripting cross-site alla divulgazione delle informazioni. Può anche disattivare alcune restrizioni di sicurezza come i filtri XSS e la stessa politica di origine nei browser della vittima, lasciandoli suscettibili ad attacchi dannosi.

Come prevenire le iniezioni di intestazione CRLF/HTTP nelle applicazioni Web

La migliore tecnica di prevenzione è quella di non utilizzare l’input degli utenti direttamente all’interno delle intestazioni di risposta. Se ciò non è possibile, dovresti sempre usare una funzione per codificare i caratteri speciali CRLF. Un’altra buona pratica per la sicurezza delle applicazioni Web è aggiornare il linguaggio di programmazione a una versione che non consente di iniettare CR e LF all’interno di funzioni che impostano le intestazioni HTTP.

Vulnerabilità Classificazione e la Gravità della Tabella