10. Security Considerations (Considerazioni sulla Sicurezza)
10.1. Server Authority (Autorità del Server)
HTTP/2 si basa sulla definizione HTTP/1.1 di autorità per determinare se un server è autorevole nel fornire una data risposta (vedere Sezione 17.1 di [HTTP]). Questo si basa sulla risoluzione dei nomi locale per lo schema "https" e sull'identità del server autenticato 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 complessità aggiuntiva considerevole.
10.2. Cross-Protocol Attacks (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 dove ALPN non è utilizzato in TLS, la prefazione della connessione client HTTP/2 (Sezione 3.4) potrebbe essere confusa con altri protocolli. La prefazione della connessione HTTP/2 è progettata per minimizzare questa possibilità selezionando una sequenza che è improbabile che sia un inizio valido per altri protocolli.
Qualsiasi protocollo che sia accessibile a un endpoint HTTP/2 può essere utilizzato per stabilire ciò che sembra essere una connessione HTTP/2 valida. Per questo motivo, la prefazione della connessione ricevuta da un endpoint lato server deve essere valida per il protocollo per formare un attacco cross-protocol.
La prefazione della connessione client (Sezione 3.4) non è sufficiente per garantire che il protocollo non sia confuso, ma fornisce una certa protezione. Le implementazioni dei 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 target 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 ed echeggiare una richiesta inviata a un altro server. Un attaccante può intercettare e modificare la risposta che il client riceve, causando al client di associare le informazioni nella risposta con una risposta a una richiesta a cui non appartiene.
10.3. Intermediary Encapsulation Attacks (Attacchi di Incapsulamento Intermediario)
La codifica dei campi HTTP/2 consente l'espressione di nomi di campo e valori che non sono nomi di campo e valori validi in HTTP/1.1 o che non possono essere espressi in HTTP/1.1. Le richieste o risposte contenenti nomi di campo o valori non validi rendono le implementazioni che eseguono una validazione insufficiente sui nomi di campo e valori vulnerabili. 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 HTTP/2 a HTTP/1.1 che non valida completamente le richieste e le risposte potrebbe consentire a un client malevolo di contrabbandare valori di campo o creare campi con nomi di campo fuorvianti.
10.4. Cacheability of Pushed Responses (Memorizzabilità nella Cache delle Risposte Spinte)
Le risposte spinte non hanno una richiesta esplicita da un client; la richiesta è fornita dal server in un frame PUSH_PROMISE.
La memorizzazione nella cache delle risposte spinte può essere problematica. A seconda delle informazioni utilizzate per stabilire la connessione, una risposta spinta potrebbe essere resa involontariamente disponibile a un nuovo client che condivide la connessione ma ha richiesto la risorsa involontariamente.
Ad esempio, nel caso dell'utilizzo di TLS per l'autenticazione, un client malevolo potrebbe ricevere una risposta spinta su informazioni sensibili di un utente autenticato utilizzando la stessa connessione.
I server DEVONO includere solo valori che sono memorizzabili nella cache nelle richieste che sono spinte (vedere Sezione 9.2.3 di [HTTP]); le richieste spinte non includono valori per il contenuto della richiesta. Le risposte spinte sono contrassegnate come non memorizzabili nella cache includendo un campo di intestazione 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 spinta può essere fornita per risposte che sono sia memorizzabili nella cache che non memorizzabili nella cache, i client potrebbero erroneamente memorizzare nella cache la risposta spinta utilizzando la risposta memorizzabile nella cache.
Pertanto, i server DOVREBBERO includere un campo di intestazione Cache-Control con un valore di "no-cache" nel frame HEADERS di un flusso spinto, a meno che non ci sia un segnale esplicito che indica che il client sta memorizzando nella cache la risposta.
10.5. Denial-of-Service Considerations (Considerazioni sul Denial-of-Service)
L'uso di HTTP/2 introduce diverse nuove opportunità di denial-of-service (DoS).
10.5.1. Limits on Field Section Size (Limiti sulla Dimensione della Sezione di Campo)
Una sezione di campo contenente un gran numero di campi o lunghi nomi di campo o valori 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 righe di campo che accetteranno e sul numero totale e sulla dimensione che invieranno, limitando così la dimensione totale dei frame che compongono una sezione di campo. I server potrebbero voler mantenere una whitelist di righe di campo, e i client potrebbero voler rifiutare righe di campo, ma entrambi DOVREBBERO registrare e tenere conto dei limiti che potrebbero ostacolare l'interoperabilità.
10.5.2. CONNECT Issues (Problemi CONNECT)
Il metodo CONNECT può essere utilizzato per creare una connessione per destinazioni non attendibili. La connessione TCP per CONNECT non è soggetta a controllo, e potrebbe tentare di connettersi a endpoint o altri dispositivi, creando un'inondazione di connessioni. Le implementazioni DOVREBBERO impostare limiti sulle destinazioni che sono permesse come target CONNECT, e DOVREBBERO registrare questi limiti.
10.5.3. Use of Compression (Uso della Compressione)
La compressione dei blocchi di campo in HTTP/2 si basa su algoritmi e stati 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 campo che richiede grandi quantità di risorse del decodificatore. Questo può essere fatto utilizzando grandi quantità di stringhe codificate Huffman o effettuando molti aggiornamenti della tabella dinamica. Iniziare immediatamente una nuova sezione di campo dopo aver terminato una (ad esempio, frame DATA vuoti seguiti da un frame HEADERS) potrebbe anche essere utilizzato per limitare le risorse del decodificatore disponibili.
Attacchi simili possono essere inviati per utilizzare aggressivamente lo stato di compressione della sezione di campo per creare risposte che richiedono grandi quantità di risorse del codificatore.
Le implementazioni DOVREBBERO impostare limiti sulla dimensione dei campi che decomprimono.
10.5.4. Use of Flow Control (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 la gestione della finestra di controllo di flusso potrebbe causare agli stream di non ottenere la finestra disponibile, rendendo lo stream incapace di progredire.
10.5.5. Use of Settings (Uso delle Impostazioni)
Un frame SETTINGS può essere utilizzato per causare a un peer di spendere tempo di elaborazione aggiuntivo. Questo potrebbe essere fatto cambiando inutilmente le impostazioni, inviando frame SETTINGS senza cambiare alcuna impostazione, o cambiando frequentemente le impostazioni.
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. Use of Priorities (Uso delle Priorità)
Le priorità potrebbero essere utilizzate per causare a un peer di spendere risorse eccessive. I cambiamenti frequenti dell'albero delle priorità o la complessità irragionevole negli alberi delle priorità possono entrambi risultare in un consumo eccessivo di CPU.
10.5.7. Use of HTTP/2 Without TLS (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 le 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. Use of Compression (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 di trasmissione.
HTTP/2 fornisce compressione in diversi luoghi: i blocchi di campo utilizzano HPACK [COMPRESSION], e i contenuti dei frame DATA possono utilizzare la codifica del contenuto (vedere Sezione 8.4.1 di [HTTP]).
HPACK è progettato per rendere più difficile sfruttare la divulgazione di segreti; tuttavia, il compromesso tra le scelte di implementazione o le protezioni dell'applicazione che possono essere realizzate in alcuni casi è imperfetto. Gli attacchi possono sfruttare il riutilizzo dello stato di compressione del campo su più richieste. Le implementazioni e le applicazioni possono scegliere di limitare la quantità di stato di compressione utilizzata tra le richieste per migliorare la protezione, ma a costo di aumentare la dimensione dei messaggi.
La compressione dei contenuti dei frame DATA è generalmente considerata più sicura perché i contenuti dei frame DATA sono meno probabili di essere mescolati con dati controllati dall'attaccante su più richieste. Tuttavia, la codifica del contenuto di compressione combina informazioni da origini diverse. Sebbene l'utilizzo di un identificatore di origine diverso distingua le informazioni da fonti diverse (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. Use of Padding (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'utilizzo dell'analisi del traffico per dedurre informazioni sui messaggi, 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 inviare 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'utilizzo del padding può ridurre alcuni attacchi (ad esempio, [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 del messaggio. Un attaccante potrebbe essere in grado di utilizzare proprietà statistiche sulla dimensione dei messaggi, il che potrebbe consentire a un attaccante di utilizzare la lunghezza dei messaggi, sia che siano imbottiti o meno, per dedurre informazioni sul contenuto con una certa probabilità.
10.8. Privacy Considerations (Considerazioni sulla Privacy)
Diverse caratteristiche di HTTP/2 offrono a un osservatore l'opportunità di correlare un insieme di richieste. Questi includono il valore delle impostazioni, il contesto di compressione per i blocchi di campo, la gestione della finestra di controllo di 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 dell'utente.
Capitolo 10 completato!
References
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"