La compressione HTTP è sicura?

Question

La compressione HTTP è sicura?

#1 da (38 voti)
#2 da (23 voti)

37

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

Ora l'attacco CRIME, almeno come è stato descritto pubblicamente finora, è un attacco alla compressione TLS. Background: TLS include un meccanismo di compressione incorporato, che avviene a livello TLS (l'intera connessione è compressa). Pertanto, abbiamo una situazione in cui i dati forniti dagli aggressori (ad es. Il corpo di una richiesta POST) vengono mescolati con i segreti (ad es. I cookie nelle intestazioni HTTP), che è ciò che ha permesso l'attacco CRIME.

Tuttavia ci sono anche altri livelli dello stack di sistema che potrebbero utilizzare la compressione. Sto pensando soprattutto alla compressione HTTP . Il protocollo HTTP ha il supporto integrato per la compressione di qualsiasi risorsa scaricata tramite 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 la supportano, ma la maggior parte dei browser e molti server 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 che vengono scaricati tramite una connessione SSL / TLS, ad esempio alle 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?

cryptography tls

posta D.W. 20.09.2012 - 02:07

fonte

2 risposte

23

La compressione, in generale, modifica la lunghezza di ciò che è compresso (è esattamente il motivo per cui lo comprimiamo). La compressione senza perdita modifica la lunghezza a seconda dei dati stessi (mentre la compressione con perdite può raggiungere una compressione fissa rapporto, ad es. un file MP3 con un rigoroso 128 kbit / s). La lunghezza dei dati è ciò che trapelano attraverso la crittografia, motivo per cui siamo interessati a questo.

In un modo molto generico, una perdita di lunghezza può essere fatale, anche in presenza di un attaccante passivo-solo; è 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 è stato inviato al colonnello ( Oberst ) mentre meno importante messaggi in cui è stato taggato un tenente ( Oberleutnant , un termine molto più lungo).

La compressione rende le perdite di lunghezza solo peggiori, perché impedisce di correggere le perdite di lunghezza normalizzando la lunghezza dei messaggi.

Quando l'attaccante può aggiungere alcuni suoi dati nei blocchi che sono compressi, amplifica la perdita di lunghezza, che può essere trasformata in un vettore di attacco pratico per dati di destinazione arbitrari, come l'attacco CRIME dimostra. Tuttavia, sostengo che il problema era già lì. In tale vista, la compressione a livello HTTP non rappresenta un nuovo rischio; è piuttosto un fattore aggravante per un rischio preesistente. Lasciando che l'hacker aggiunga alcuni dei propri dati nel flusso crittografato è ancora un altro fattore aggravante e questi fattori si sommano.

Scommetto che non sei il primo ad avere questa idea. Non solo un bel po 'di 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, questo è l'attaccante che ha scelto i dati riflessi, potrebbe essere divertente! Proviamo di nuovo con un URL HTTPS:

https://www.google.com/sdfdfskfdjsdfhfkjsbkfbsjksalakjsflfa

e poi, no 404, non è divertente, verrai reindirettamente guidato verso la home page di Google. Questo mi fa pensare che alcuni utenti di Google ci avessero già pensato e disattivato in modo proattivo il bit di riflessione quando si utilizza SSL (perché quando si utilizza SSL, si ottengono i campanelli e i fischi di Google+, quindi dati potenzialmente pericolosi).

risposta data 20.09.2012 - 03:05

fonte

Leggi altre domande sui tag cryptography tls

Quali sono gli scopi di queste politiche di sicurezza? Se l'e-mail non è sicura, perché la usiamo per reimpostare la password?

score 38 · Accepted Answer

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 potrebbe essere pericolosa. Mi sembra che la compressione HTTP possa, in alcune circostanze, consentire attacchi tipo CRIME.

Considera un'applicazione web con una pagina dinamica con le seguenti caratteristiche:

Viene pubblicato su HTTPS.
La compressione HTTP è supportata dal server (questa pagina verrà inviata al browser in forma compressa, se il browser supporta la compressione HTTP).
La pagina ha un token CSRF su di esso da qualche parte. Il token CSRF è fisso per la durata della sessione (per esempio). Questo è il segreto che l'attacco proverà ad imparare.
La pagina contiene alcuni contenuti dinamici che possono essere specificati dall'utente. Per semplicità, supponiamo che ci sia un parametro URL che viene risuonato direttamente nella pagina (magari con qualche escape HTML applicato per prevenire XSS, ma che va bene e non scoraggerà l'attacco descritto).

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

Lasciatemi fare un esempio. Supponiamo che l'applicazione Web di destinazione sia un sito Web bancario su www.bank.com e che la pagina vulnerabile sia https://www.bank.com/buggypage.html . Supponiamo che la banca assicuri che il materiale bancario sia accessibile solo tramite SSL (https). E, supponiamo che se il browser visita https://www.bank.com/buggypage.html?name=D.W. , il server risponderà con un documento HTML con un aspetto 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 collegato alla tua banca, quindi il tuo browser ha una sessione aperta con il sito web della tua banca, ma in realtà non stai facendo alcuna operazione bancaria sulla connessione Wifi aperta. Supponiamo inoltre che l'aggressore possa attirarti a visitare il sito web dell'attaccante http://www.evil.com/ (ad esempio, magari facendo un attacco man-in-the-middle a te e reindirizzandoti quando provi a visitare un altro sito http).

Quindi, quando il tuo browser visita http://www.evil.com/ , quella pagina può attivare richieste interdominio sul 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 di visualizzare la risposta a una richiesta interdominio. Tuttavia, poiché l'utente malintenzionato può intercettare il traffico di rete, l'utente malintenzionato 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 propria banca.

In particolare, la pagina dannosa http://www.evil.com/ può attivare una richiesta a https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1 e guardare quanto bene la pagina HTML risultante si comprime (ascoltando 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 vedere quanto bene comprime 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'aggressore di apprendere la prima cifra del token CSRF.

In questo modo, sembra che l'attaccante possa apprendere ciascuna cifra del token CSRF, recuperandole cifra per cifra, finché l'attaccante non impara l'intero token CSRF. Quindi, una volta che l'hacker conosce il token CSRF, può fare in modo che la sua pagina dannosa su www.evil.com attivi una richiesta interdominio contenente il token CSRF appropriato, riuscendo a sconfiggere le protezioni CSRF della banca.

Sembra che questo possa consentire a un utente malintenzionato di eseguire un attacco CSRF con successo su applicazioni Web, quando si applicano le condizioni sopra riportate, se la compressione HTTP è abilitata. L'attacco è possibile perché stiamo mescolando i segreti con i dati controllati dagli hacker nello stesso carico utile e quindi comprimendo e crittografando quel carico utile.

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 che sto pensando. Quindi, mi sembra che usare la compressione HTTP su pagine dinamiche a cui si accede tramite HTTPS sia un po 'rischioso. Potrebbero esserci validi motivi per disabilitare la compressione HTTP su tutte le risorse pubblicate su HTTPS, ad eccezione delle pagine / risorse statiche (ad es. CSS, Javascript).