10. Considerazioni sulla Sicurezza
10.1. Autorità del Server
HTTP/2 si basa sulla definizione di autorità di HTTP/1.1 per determinare se un server è autorizzato a fornire una determinata risposta (vedere Sezione 17.1 di [HTTP]). Questo si basa sulla risoluzione dei nomi locale per lo schema "https" e sull'identità del server autenticata per lo schema "https" (come definito nella Sezione 4.2.2 di [HTTP]). I servizi alternativi ([ALT-SVC]) utilizzati per stabilire l'autorità potrebbero introdurre una notevole complessità aggiuntiva.
10.2. Attacchi Cross-Protocol
In TLS, HTTP/2 utilizza l'estensione Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN] per negoziare l'uso del protocollo. Questo crea un segnale positivo che il server supporta HTTP/2 e riduce l'esposizione di HTTP/2 agli attacchi cross-protocol.
Tuttavia, in chiaro o quando ALPN non è utilizzato in TLS, il prefisso di connessione client HTTP/2 (Sezione 3.4) potrebbe essere confuso con altri protocolli. Il prefisso di connessione HTTP/2 è progettato per minimizzare questa possibilità selezionando una sequenza che è improbabile essere un inizio valido per altri protocolli.
Qualsiasi protocollo accessibile a un endpoint HTTP/2 può essere utilizzato per stabilire quella che appare come una connessione HTTP/2 valida. Per questo motivo, il prefisso di connessione ricevuto da un endpoint lato server deve essere valido affinché il protocollo formi un attacco cross-protocol.
Il prefisso di connessione client (Sezione 3.4) non è sufficiente per garantire che il protocollo non sia confuso, ma fornisce una certa protezione. Le implementazioni client HTTP/2 potrebbero anche dover eseguire controlli aggiuntivi prima di applicare la semantica HTTP. In particolare, i client devono assicurarsi che la risposta iniziale sia una risposta legittima a un messaggio che il client ha inviato.
Un server potrebbe attaccare un client inviando una richiesta a un server di destinazione che il client voleva inviare a un server diverso. Se il server ricevente supporta uno schema HTTP diverso da HTTP/2, il server può leggere e ripetere una richiesta inviata a un altro server. Un attaccante può intercettare e modificare la risposta che il client riceve, facendo sì che il client associ informazioni nella risposta con una risposta a una richiesta a cui non appartiene.
10.3. Attacchi di Incapsulamento degli Intermediari
La codifica dei campi HTTP/2 consente l'espressione di nomi e valori di campi che non sono nomi e valori di campi validi in HTTP/1.1 o che non possono essere espressi in HTTP/1.1. Le richieste o risposte contenenti nomi o valori di campi non validi rendono vulnerabili le implementazioni che eseguono una validazione insufficiente sui nomi e valori dei campi. Un attaccante potrebbe essere in grado di utilizzare un intermediario per incapsulare una richiesta o risposta in modo tale che un messaggio non valido appaia valido.
Un traduttore da HTTP/2 a HTTP/1.1 che non valida completamente richieste e risposte potrebbe consentire a un client malevolo di contrabbandare valori di campi o creare campi con nomi di campi fuorvianti.
10.4. Cacheability delle Risposte Pushed
Le risposte pushed non hanno una richiesta esplicita da un client; la richiesta è fornita dal server in un frame PUSH_PROMISE.
Il caching delle risposte pushed può essere problematico. A seconda delle informazioni utilizzate per stabilire la connessione, una risposta pushed potrebbe essere inavvertitamente resa disponibile a un nuovo client che condivide la connessione ma ha richiesto involontariamente la risorsa.
Ad esempio, nel caso dell'uso di TLS per l'autenticazione, un client malevolo potrebbe ricevere una risposta pushed su informazioni sensibili di un utente autenticato che utilizza la stessa connessione.
I server DEVONO includere solo valori che sono cacheable nelle richieste che vengono pushed (vedere Sezione 9.2.3 di [HTTP]); le richieste pushed non includono valori per il contenuto della richiesta. Le risposte pushed sono contrassegnate come non cacheable includendo un campo header Cache-Control contenente la direttiva di risposta cache no-cache o private (vedere Sezione 5.2.2.4 di [HTTP-CACHING]).
Se la stessa risposta pushed può essere fornita per risposte che sono sia cacheable che non cacheable, i client potrebbero memorizzare nella cache in modo errato la risposta pushed utilizzando la risposta cacheable.
Pertanto, i server DOVREBBERO includere un campo header Cache-Control con un valore di "no-cache" nel frame HEADERS di uno stream pushed, a meno che non ci sia un segnale esplicito che indica che il client sta memorizzando nella cache la risposta.
10.5. Considerazioni sul Denial-of-Service
L'uso di HTTP/2 introduce diverse nuove opportunità di denial-of-service (DoS).
10.5.1. Limiti sulla Dimensione della Sezione dei Campi
Una sezione di campi contenente un gran numero di campi o nomi o valori di campi lunghi può causare a un'implementazione di consumare quantità eccessive di memoria, tempo CPU, o entrambi.
Le implementazioni DOVREBBERO imporre limiti sul numero totale e sulla dimensione delle linee di campi che accetteranno e sul numero totale e sulla dimensione che invieranno, limitando così la dimensione totale dei frame che compongono una sezione di campi. I server potrebbero voler mantenere una whitelist di linee di campi, e i client potrebbero voler rifiutare linee di campi, ma entrambi DOVREBBERO registrare e tenere conto dei limiti che potrebbero ostacolare l'interoperabilità.
10.5.2. Problemi CONNECT
Il metodo CONNECT può essere utilizzato per creare una connessione verso destinazioni non affidabili. La connessione TCP per CONNECT non è soggetta a controllo, e potrebbe tentare di connettersi a endpoint o altri dispositivi, creando un flood di connessioni. Le implementazioni DOVREBBERO impostare limiti sulle destinazioni che sono consentite come target CONNECT, e DOVREBBERO registrare questi limiti.
10.5.3. Uso della Compressione
La compressione dei blocchi di campi in HTTP/2 si basa su algoritmi e stato che possono essere utilizzati da un attaccante per causare denial of service.
Un attaccante può inviare richieste con campi accuratamente costruiti per creare una sezione di campi che richiede grandi quantità di risorse del decoder. Questo può essere fatto utilizzando grandi quantità di stringhe codificate Huffman o effettuando molti aggiornamenti alla tabella dinamica. Avviare immediatamente una nuova sezione di campi dopo averne terminata una (ad es. frame DATA vuoti seguiti da un frame HEADERS) potrebbe anche essere utilizzato per limitare le risorse del decoder disponibili.
Attacchi simili possono essere inviati per utilizzare aggressivamente lo stato di compressione della sezione di campi per creare risposte che richiedono grandi quantità di risorse dell'encoder.
Le implementazioni DOVREBBERO impostare limiti sulla dimensione dei campi che decomprimono.
10.5.4. Uso del Controllo di Flusso
Il controllo di flusso in HTTP/2 consente a un avversario di limitare la quantità di dati che un peer può inviare. L'implementazione degli aggiornamenti della finestra o della gestione della finestra di controllo del flusso potrebbe impedire agli stream di ottenere finestra disponibile, rendendo lo stream incapace di fare progressi.
10.5.5. Uso delle Impostazioni
Un frame SETTINGS può essere utilizzato per causare a un peer di spendere tempo di elaborazione aggiuntivo. Questo può essere fatto cambiando le impostazioni senza scopo, inviando frame SETTINGS senza cambiare alcuna impostazione, o cambiando le impostazioni frequentemente.
Altri parametri SETTINGS che limitano i valori potrebbero essere utilizzati per consumare risorse, come disabilitare la tabella dinamica HPACK impostando un valore molto piccolo per il parametro SETTINGS_HEADER_TABLE_SIZE.
Gli endpoint DOVREBBERO rilevare questi comportamenti e trattarli come un errore di connessione (Sezione 5.4.1) di tipo ENHANCE_YOUR_CALM.
10.5.6. Uso delle Priorità
Le priorità potrebbero essere utilizzate per causare a un peer di spendere risorse eccessive. Cambiamenti frequenti all'albero delle priorità o complessità irragionevole negli alberi delle priorità possono entrambi risultare in consumo eccessivo di CPU.
10.5.7. Uso di HTTP/2 senza TLS
HTTP/2 può essere distribuito senza utilizzare TLS. Questa modalità ha le stesse vulnerabilità a certi attacchi di HTTP/1.1. Le implementazioni che utilizzano questa modalità di operazione DOVREBBERO applicare protezioni applicabili a HTTP/1.1.
Le implementazioni devono anche essere consapevoli che molte funzionalità HTTP/2 potrebbero essere più vulnerabili agli attacchi senza TLS. In particolare, l'assenza di protezione della riservatezza e protezione dell'integrità fornita da TLS significa che la crittografia o l'integrità dei dati è a rischio.
10.6. Uso della Compressione
La compressione può consentire a un attaccante di recuperare contenuti segreti di comunicazioni crittografate quando quella compressione è combinata con dati controllati da un attaccante e dati segreti di cui l'attaccante può osservare la dimensione della trasmissione.
HTTP/2 fornisce compressione in diversi punti: i blocchi di campi utilizzano HPACK [COMPRESSION], e il contenuto dei frame DATA può utilizzare la codifica del contenuto (vedere Sezione 8.4.1 di [HTTP]).
HPACK è progettato per rendere più difficile lo sfruttamento della divulgazione di segreti; tuttavia, il compromesso tra scelte di implementazione o protezioni dell'applicazione che possono essere realizzate in alcuni casi è imperfetto. Gli attacchi possono sfruttare il riutilizzo dello stato di compressione dei campi attraverso più richieste. Le implementazioni e le applicazioni possono scegliere di limitare la quantità di stato di compressione utilizzato attraverso le richieste per migliorare la protezione, ma a costo di aumentare la dimensione dei messaggi.
La compressione del contenuto dei frame DATA è generalmente considerata più sicura perché il contenuto dei frame DATA è meno probabile che sia mescolato con dati controllati dall'attaccante attraverso più richieste. Tuttavia, la codifica del contenuto di compressione combina informazioni da diverse origini. Sebbene l'uso di un identificatore di origine diverso distingua le informazioni da diverse fonti (vedere Sezione 11.5 di [HTTP]), la compressione può rimuovere questi separatori, come descritto in [BREACH].
La disabilitazione o la limitazione della compressione per la codifica del contenuto è generalmente considerata sufficiente per mitigare questi attacchi, ma questo potrebbe non essere adeguato per prevenire tutti gli attacchi.
10.7. Uso del Padding
Il padding può essere utilizzato per oscurare la dimensione esatta del contenuto di frame e messaggi. Il padding può essere utilizzato per mitigare gli attacchi che si basano sull'uso dell'analisi del traffico per dedurre informazioni sui messaggi, il che è di particolare importanza per HTTP, dove la lunghezza dei messaggi compressi potrebbe rivelare informazioni sul contenuto che contengono.
Un esempio di utilizzo del padding sarebbe l'invio di un gran numero di frame HEADERS e DATA con dimensioni di payload che variano tra i frame per oscurare la dimensione esatta di un messaggio. L'uso del padding può ridurre alcuni attacchi (ad es. [BREACH]).
In generale, l'esistenza di attacchi di analisi del traffico significa che il padding a una dimensione fissa per ogni campo o frame è insufficiente per fornire protezione. Per essere efficiente e fornire un certo livello di protezione, il padding DOVREBBE essere scelto casualmente.
Il padding non è una protezione perfetta per oscurare la dimensione dei messaggi. Un attaccante potrebbe essere in grado di utilizzare proprietà statistiche sulla dimensione dei messaggi, che potrebbero consentire a un attaccante di utilizzare la lunghezza dei messaggi, sia con padding che senza, per dedurre informazioni sul contenuto con una certa probabilità.
10.8. Considerazioni sulla Privacy
Diverse caratteristiche di HTTP/2 forniscono a un osservatore l'opportunità di correlare un insieme di richieste. Queste includono il valore delle impostazioni, il contesto di compressione per i blocchi di campi, la gestione della finestra di controllo del flusso, e il timing dei messaggi in arrivo.
In particolare, i campi HTTP contenenti informazioni sull'identità dell'utente possono essere correlati con altre comunicazioni, anche quando si utilizzano server diversi.
HTTP/2 non fornisce meccanismi specifici per proteggere la privacy degli utenti.
Capitolo 10 completato!
Riferimenti
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"