Comprendere l'iniezione CRLF: una vulnerabilità e mitigazione delle applicazioni Web

Home » Sicurezza informatica » Sicurezza delle applicazioni » Comprendere l'iniezione CRLF: una vulnerabilità e mitigazione delle applicazioni Web

L'iniezione CRLF (Carriage Return Line Feed) è una vulnerabilità dell'applicazione Web che si verifica quando un utente malintenzionato può inserire caratteri CRLF dannosi in una risposta HTTP. Questa vulnerabilità può portare a vari problemi di sicurezza, come l'inserimento di intestazioni HTTP, la suddivisione della risposta HTTP, la correzione delle sessioni, il cross-site scripting (XSS) e l'avvelenamento della cache.

Per comprendere l'iniezione CRLF, analizziamo il termine:

Ritorno a capo (CR):È un carattere di controllo (codice ASCII 13) che ordina al cursore di tornare all'inizio della riga corrente.

Avanzamento riga (LF):È un carattere di controllo (codice ASCII 10) che ordina al cursore di spostarsi alla riga successiva.

Nel contesto HTTP, CRLF si riferisce alla sequenza di caratteri CR e LF (“\r\n”). Questi caratteri vengono utilizzati per separare le righe nel protocollo HTTP.

La vulnerabilità dell'iniezione CRLF si verifica quando i dati controllati dall'utente (input) non vengono adeguatamente disinfettati o convalidati prima di essere utilizzati nella costruzione di una risposta HTTP. Gli aggressori sfruttano questa vulnerabilità inserendo caratteri CRLF nell'input dell'utente con l'obiettivo di manipolare la risposta HTTP.

L'iniezione CRLF può essere utilizzata come parte di una catena di vulnerabilità per sfruttare vari problemi di sicurezza. Ecco alcune vulnerabilità comuni della catena che possono essere sfruttate insieme all'iniezione CRLF:

L'iniezione CRLF può essere combinata con altre vulnerabilità, come una convalida inadeguata dell'input o una concatenazione non sicura dell'input dell'utente, per eseguire attacchi di suddivisione della risposta HTTP. Inserendo caratteri CRLF, un utente malintenzionato può manipolare le intestazioni della risposta e potenzialmente dividere la risposta in più parti, portando a vari problemi di sicurezza come avvelenamento della cache, correzione della sessione o scripting cross-site (XSS).

Esempio:

Consideriamo un esempio diverso in cui il segmento di codice legge l'indirizzo email di un utente da una richiesta HTTP e lo imposta come intestazione del cookie in una risposta HTTP:

In questo esempio, l'applicazione prende l'indirizzo email inviato nella richiesta e lo imposta come cookie denominato "user_email" nella risposta HTTP.

Supponiamo che nella richiesta sia inviato l'indirizzo email "[email protected]". La risposta HTTP che include questo cookie potrebbe assomigliare a questa:

Questa risposta mantiene la forma prevista perché l'input ("[email protected]") è un indirizzo email valido senza caratteri dannosi.

Consideriamo ora cosa succede se un utente malintenzionato invia un indirizzo email dannoso contenente caratteri CRLF:

Il valore per il parametro "email" è "john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a". Quando l'applicazione elabora questo input e imposta il cookie, la risposta HTTP potrebbe essere manipolata come segue

In questo caso, l’aggressore ha inserito caratteri CRLF (“%0d%0a”) nel parametro email, che hanno portato all’inserimento di un’ulteriore intestazione “Set-Cookie” nella risposta. L'aggressore ha effettivamente impostato un altro cookie denominato "admin" con il valore "true". Questo potrebbe essere utilizzato per l'escalation dei privilegi o altri attacchi relativi alla sicurezza.

L'iniezione CRLF può essere utilizzata come trampolino di lancio per attacchi di scripting cross-site. Inserendo caratteri CRLF per manipolare la risposta, un utente malintenzionato può introdurre script dannosi che possono essere eseguiti nel contesto di altri utenti, portando al dirottamento della sessione, al furto di dati o ad altre forme di accesso non autorizzato.

Esempio:

Lasciamo creare un payload per escalare CRLF a Cross Site Scripting (XSS):

Durante l'esecuzione di un VAPT (Vulnerability Assessment and Penetration Testing) su un'applicazione web, ho scoperto una potenziale vulnerabilità CRLF (Carriage Return Line Feed). Si prega di trovare la spiegazione per il rilevamento e lo sfruttamento della vulnerabilità CRLF con la prova del concetto:

Aggiungendo un commento, tutte le intestazioni e i contenuti non necessari vengono commentati. Viene utilizzato il commento HTML perché la risposta ha un'intestazione Content-Type:text/html.