it-swarm.dev

La compressione HTTP è sicura?

L'attacco CRIME ci ha insegnato che l'uso della compressione può mettere in pericolo la riservatezza. In particolare, è pericoloso concatenare i dati forniti dagli aggressori con dati segreti sensibili e quindi comprimere e crittografare la concatenazione; ogni volta che vediamo che si verificano, a qualsiasi livello dello stack di sistema, dovremmo essere sospettosi del potenziale per attacchi simili al CRIME.

Ora l'attacco CRIME, almeno come è stato finora pubblicamente descritto, è un attacco alla compressione TLS. Background: TLS include un meccanismo di compressione incorporato, che si verifica a livello di TLS (l'intera connessione è compressa). Pertanto, abbiamo una situazione in cui i dati forniti dall'aggressore (ad esempio, il corpo di un POST) si mescola con i segreti (ad esempio, i cookie nelle intestazioni HTTP), che è ciò che ha abilitato il CRIMINE attacco.

Tuttavia, ci sono anche altri livelli dello stack di sistema che possono utilizzare la compressione. Sto pensando in particolare a compressione HTTP . Il protocollo HTTP ha il supporto integrato per la compressione di qualsiasi risorsa scaricata su HTTP. Quando la compressione HTTP è abilitata, la compressione viene applicata al corpo della risposta (ma non alle intestazioni). La compressione HTTP sarà abilitata solo se sia il browser che il server lo supportano, ma la maggior parte dei browser e molti server lo fanno, perché migliora le prestazioni . Si noti che la compressione HTTP è un meccanismo diverso dalla compressione TLS; La compressione HTTP viene negoziata a un livello superiore dello stack e si applica solo al corpo della risposta. Tuttavia, la compressione HTTP può essere applicata ai dati scaricati tramite una connessione SSL/TLS, ovvero a risorse scaricate tramite HTTPS.

La mia domanda: la compressione HTTP è sicura da usare, sulle risorse HTTPS? Devo fare qualcosa di speciale per disabilitare la compressione HTTP delle risorse a cui si accede tramite HTTPS? Oppure, se la compressione HTTP è in qualche modo sicura, perché è sicura?

43
D.W.

Mi sembra rischioso. La compressione HTTP va bene per le risorse statiche, ma per alcune risorse dinamiche servite su SSL, sembra che la compressione HTTP possa essere pericolosa. Mi sembra che la compressione HTTP possa, in alcune circostanze, consentire attacchi di tipo CRIME.

Si consideri un'applicazione Web che ha una pagina dinamica con le seguenti caratteristiche:

  1. Viene servito su HTTPS.

  2. La compressione HTTP è supportata dal server (questa pagina verrà inviata al browser in forma compressa, se il browser supporta la compressione HTTP).

  3. La pagina ha un token CSRF su di essa da qualche parte. Il token CSRF è stato risolto per la durata della sessione (diciamo). Questo è il segreto che l'attacco proverà ad imparare.

  4. La pagina contiene alcuni contenuti dinamici che possono essere specificati dall'utente. Per semplicità, supponiamo che ci sia qualche parametro URL che viene ripetuto direttamente nella pagina (forse con un po 'di escape HTML applicato per impedire XSS, ma va bene e non scoraggerà l'attacco descritto).

Quindi penso che gli attacchi in stile CRIME potrebbero consentire a un utente malintenzionato di apprendere il token CSRF e montare attacchi CSRF sul sito Web.

Lasciami fare un esempio. Supponiamo che l'applicazione Web di destinazione sia un sito Web bancario su www.bank.com e la pagina vulnerabile è https://www.bank.com/buggypage.html. Supponiamo che la banca assicuri che le attività bancarie siano accessibili solo tramite SSL (https). E supponiamo che se il browser visita https://www.bank.com/buggypage.html?name=D.W., quindi il server risponderà con un documento HTML simile a qualcosa di vagamente simile a questo:

<html>...<body>
Hi, D.W.!  Pleasure to see you again.  Some actions you can take:
<a href="/closeacct&csrftoken=29238091">close my account</a>,
<a href="/viewbalance&csrftoken=...">view my balance</a>, ...
</body></html>

Supponiamo che tu stia navigando sul Web tramite una connessione Wifi aperta, in modo che un utente malintenzionato possa intercettare tutto il traffico di rete. Supponiamo che tu sia attualmente connesso alla tua banca, quindi il tuo browser ha una sessione aperta con il sito web della tua banca, ma in realtà non stai effettuando alcuna attività bancaria tramite la connessione Wifi aperta. Supponiamo inoltre che l'attaccante possa attirarti a visitare il sito Web dell'attaccante http://www.evil.com/ (ad esempio, magari facendo un attacco man-in-the-middle su di te e reindirizzandoti quando provi a visitare qualche altro sito http).

Quindi, quando il browser visita http://www.evil.com/, quella pagina può attivare richieste tra domini al sito Web della tua banca, nel tentativo di apprendere il token CSRF segreto. Si noti che Javascript è autorizzato a effettuare richieste tra domini. La politica della stessa origine impedisce che venga visualizzata la risposta a una richiesta tra domini. Tuttavia, poiché l'aggressore può intercettare il traffico di rete, l'attaccante può osservare la lunghezza di tutti i pacchetti crittografati e quindi dedurre qualcosa sulla lunghezza delle risorse che vengono scaricate tramite la connessione SSL alla tua banca.

In particolare, il maligno http://www.evil.com/ page può attivare una richiesta a https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1 e guarda come si comprime bene la pagina HTML risultante (intercettando i pacchetti e osservando la lunghezza del pacchetto SSL dalla banca). Successivamente, può attivare una richiesta a https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2 e vedi quanto comprime bene la risposta. E così via, per ogni possibilità per la prima cifra del token CSRF. Uno di questi dovrebbe comprimersi un po 'meglio degli altri: quello in cui la cifra nel parametro URL corrisponde al token CSRF nella pagina. Ciò consente all'attaccante di apprendere la prima cifra del token CSRF.

In questo modo, sembra che l'attaccante possa apprendere ogni cifra del token CSRF, recuperandole cifra per cifra, fino a quando l'attaccante apprende l'intero token CSRF. Quindi, una volta che l'utente malintenzionato conosce il token CSRF, può avere la sua pagina dannosa su www.evil.com attiva una richiesta tra domini che contiene il token CSRF appropriato, annullando correttamente le protezioni CSRF della banca.

Sembra che ciò possa consentire a un utente malintenzionato di montare un attacco CSRF riuscito su applicazioni Web, quando si applicano le condizioni sopra, se la compressione HTTP è abilitata. L'attacco è possibile perché stiamo mescolando segreti con dati controllati dall'aggressore nello stesso payload, quindi comprimendo e crittografando tale payload.

Se ci sono altri segreti che sono memorizzati in HTML dinamico, potrei immaginare che attacchi simili potrebbero diventare possibili per imparare quei segreti. Questo è solo un esempio del tipo di attacco a cui sto pensando. Quindi, mi sembra che l'uso della compressione HTTP su pagine dinamiche a cui si accede tramite HTTPS sia un po 'rischioso. Potrebbero esserci buoni motivi per disabilitare la compressione HTTP su tutte le risorse offerte su HTTPS, ad eccezione di pagine/risorse statiche (ad es. CSS, Javascript).

50
D.W.

La compressione, in generale, altera la lunghezza di ciò che è compresso (questo è esattamente il motivo per cui comprimiamo). Compressione senza perdita di dati modifica la lunghezza in base ai dati stessi (mentre la compressione con perdita può raggiungere un rapporto di compressione fisso, ad esempio un file MP3 a 128 kbit/s rigorosi). La lunghezza dei dati è ciò che perde attraverso la crittografia, motivo per cui ci interessa.

In un modo molto generico, una perdita di lunghezza può essere fatale, anche in presenza di un attaccante solo passivo; è una specie di analisi del traffico . Un esempio è della prima guerra mondiale, in cui i crittografi francesi potevano prevedere l'importanza di un messaggio in base alla lunghezza dell'intestazione (crittografata): un messaggio importante veniva inviato al colonnello ( Oberst ) mentre i messaggi meno importanti sono stati taggati per un tenente ( Oberleutnant , un termine molto più lungo).

La compressione peggiora ulteriormente le perdite di lunghezza, poiché impedisce di correggere le perdite di lunghezza normalizzando le lunghezze dei messaggi.

Quando l'attaccante può aggiungere alcuni suoi dati nei blocchi compressi, amplifica la perdita di lunghezza, che può diventare un vettore di attacco pratico per dati target arbitrari, come dimostra l'attacco CRIME. Tuttavia, sostengo che il problema era già presente. In tale prospettiva, la compressione a livello HTTP non rappresenta un nuovo rischio; è piuttosto un fattore aggravante di un rischio preesistente. Consentire all'aggressore di aggiungere alcuni dei propri dati nel flusso crittografato è un altro fattore aggravante e questi fattori si sommano.


Scommetto che non sei il primo ad avere questa idea. Non solo molte persone (me incluso) ci hanno pensato negli ultimi 10 giorni, ma se provi ad accedere a questo URL:

http://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

quindi ricevi un errore 404 da Google, che contiene la parola "sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa". Ehi, è un utente malintenzionato scelto dati riflessi, potrebbe essere divertente! Quindi riproviamo con un URL HTTPS:

https://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

e poi, no 404, niente divertimento, verrai reindirizzato senza tante cerimonie alla home page di Google. Questo mi fa pensare che anche alcune persone di Google ci abbiano già pensato e disattivato in modo proattivo il bit di riflessione quando si utilizza SSL (perché quando si utilizza SSL, si ottengono le campane e i fischi di Google+, quindi dati potenzialmente pericolosi).

26
Thomas Pornin