9. Considerazioni sulla sicurezza (Security Considerations)
Questa sezione ha lo scopo di informare sviluppatori, fornitori di informazioni e utenti dei problemi di sicurezza noti rilevanti per la semantica HTTP e il suo utilizzo per trasferire informazioni su Internet. Le considerazioni relative alla sintassi, all'analisi e al routing dei messaggi sono discusse in [RFC7230], e le considerazioni relative al caching HTTP sono discusse in [RFC7234].
L'elenco delle considerazioni qui di seguito non è esaustivo. La maggior parte delle preoccupazioni di sicurezza relative alla semantica HTTP riguarda la protezione delle applicazioni lato server (codice dietro l'interfaccia HTTP), la protezione dell'elaborazione da parte dell'agente utente del contenuto ricevuto tramite HTTP o l'uso sicuro delle informazioni ottenute dai campi di intestazione HTTP. Molte di queste preoccupazioni sono interdipendenti; una debolezza nel software client può essere utilizzata per sfruttare vulnerabilità nel software server, e viceversa.
9.1. Attacchi basati su nomi di file e percorsi (Attacks Based on File and Path Names)
I server di origine utilizzano frequentemente il loro file system locale per gestire la mappatura dall'URI di destinazione alle rappresentazioni delle risorse. La maggior parte dei file system non è progettata per proteggere contro nomi di file o percorsi dannosi. Pertanto, un server di origine deve evitare di accedere a nomi che hanno un significato speciale per il sistema durante la mappatura della risorsa di destinazione su file, cartelle o directory.
Ad esempio, UNIX, Microsoft Windows e altri sistemi operativi utilizzano ".." come componente di percorso per indicare un livello di directory sopra quello corrente, e utilizzano percorsi o nomi di file denominati in modo speciale per inviare dati ai dispositivi di sistema. Convenzioni di denominazione simili potrebbero esistere all'interno di altri tipi di sistemi di archiviazione. Allo stesso modo, i sistemi di archiviazione locali hanno una tendenza fastidiosa a preferire la facilità d'uso rispetto alla sicurezza quando gestiscono caratteri non validi o inaspettati, ricomponendoli in modi che possono risultare in pattern non intenzionali.
Le implementazioni devono fare attenzione a non eseguire l'escape o l'unescape della stessa stringa più di una volta, poiché l'unescape di una stringa precedentemente sottoposta a escape può risultare in caratteri non sicuri. In particolare, non è sicuro semplicemente eseguire l'unescape della destinazione della richiesta e utilizzarla come percorso del file system senza controlli aggiuntivi.
Si noti che le restrizioni sugli URI di destinazione in questa specifica non sono sufficienti per prevenire questi tipi di attacchi; devono essere integrate da controlli specifici dell'implementazione.
9.2. Attacchi basati sull'iniezione di comandi, codice o query (Attacks Based on Command, Code, or Query Injection)
I server di origine utilizzano spesso parametri all'interno dell'URI come mezzo per identificare i servizi di sistema, selezionare voci del database o scegliere un'origine dati. Tuttavia, i dati ricevuti in una richiesta non possono essere considerati affidabili. Un attaccante potrebbe costruire uno qualsiasi degli elementi di dati della richiesta (metodo, destinazione della richiesta, campi di intestazione o corpo) per contenere dati che potrebbero essere interpretati erroneamente come comando, codice o query quando passati attraverso un'invocazione di comando, un interprete di linguaggio o un'interfaccia di database.
Ad esempio, l'iniezione SQL è un attacco comune in cui viene inserito un linguaggio di query aggiuntivo all'interno di una parte della destinazione della richiesta o dei campi di intestazione (ad esempio, Host, Referer, ecc.). Se i dati ricevuti vengono utilizzati direttamente all'interno di un'istruzione SQL SELECT, il linguaggio di query potrebbe essere interpretato come comando del database anziché come semplice valore di stringa. Questo tipo di vulnerabilità dell'implementazione è estremamente comune, nonostante sia facile da prevenire.
In generale, le implementazioni delle risorse dovrebbero (ought to) evitare l'uso dei dati di richiesta nell'assemblaggio di comandi shell o query. Quando tale uso è necessario, i dati devono essere adeguatamente sottoposti a escape (appropriato per il sistema che riceve i dati) prima di essere utilizzati.
9.3. Divulgazione di informazioni personali (Disclosure of Personal Information)
I client hanno spesso accesso a grandi quantità di informazioni personali, tra cui sia informazioni fornite dall'utente per interagire con le risorse (ad esempio, nome dell'utente, posizione, indirizzo email, password, chiavi di crittografia, ecc.) sia informazioni sull'attività di navigazione dell'utente nel tempo (ad esempio, cronologia, segnalibri, ecc.). Le implementazioni devono prevenire la divulgazione involontaria di tali informazioni.
9.3.1. Divulgazione tramite dati dell'applicazione (Disclosure via Application Data)
Le applicazioni dovrebbero (ought to) limitare la loro divulgazione di informazioni a ciò che è richiesto per completare la richiesta ed evitare la divulgazione di informazioni specifiche dell'utente o della struttura interna dell'applicazione (Sezione 5.5.3 e Sezione 7.4.2).
9.3.2. Divulgazione tramite Referer (Disclosure via Referer)
Il campo di intestazione Referer consente a un client di pubblicizzare al server da dove il client ha ottenuto la destinazione della richiesta, il che può rivelare informazioni sul contesto dell'utente o sulla cronologia di navigazione. Nel caso in cui la destinazione della richiesta sia stata fornita da una fonte di terze parti, l'utente potrebbe desiderare mantenere tali informazioni riservate (ad esempio, un collegamento da informazioni mediche). L'agente utente dovrebbe quindi (ought to) dare all'utente l'opzione di non inviare il campo Referer, o di inviare una versione meno rivelatrice (ad esempio, solo l'origine) del campo (Sezione 5.5.2).
I client non dovrebbero (ought not to) includere un campo di intestazione Referer in una richiesta HTTP (non sicura) se la pagina di riferimento è stata ricevuta con un protocollo sicuro.
Gli autori di servizi che utilizzano il protocollo HTTP non dovrebbero (ought not to) utilizzare richieste GET e POST con contenuto codificato in forma per trasmettere informazioni sensibili come informazioni di identificazione personale, numeri di conto, password, ecc., poiché ciò causa la trasmissione non crittografata di tali dati nella destinazione della richiesta o nel contenuto. I progettisti di servizi dovrebbero (ought to) utilizzare il metodo POST con corpi di messaggio per trasmettere tali informazioni sensibili, prestando attenzione a non includere tali informazioni nella destinazione della richiesta, poiché ciò potrebbe essere esposto nei log, nei segnalibri, ecc.
9.3.3. Divulgazione tramite User-Agent (Disclosure via User-Agent)
Il campo di intestazione User-Agent contiene spesso informazioni sufficienti per identificare in modo univoco un dispositivo specifico, di solito quando combinato con altre caratteristiche, in particolare se l'agente utente invia dettagli eccessivi sul sistema dell'utente o sulle estensioni. Le implementazioni dovrebbero (ought to) limitare tali informazioni (Sezione 5.5.3).
9.4. Privacy delle informazioni del log del server (Privacy of Server Log Information)
Un server è in grado di salvare dati personali sulle richieste di un utente nel tempo, il che potrebbe identificare i loro modelli di lettura o argomenti di interesse. In particolare, le informazioni del log raccolte presso un intermediario contengono spesso una cronologia dell'interazione dell'agente utente, attraverso una moltitudine di siti, che può essere ricondotta a singoli utenti.
Le informazioni del log HTTP sono di natura riservata; la loro gestione è spesso vincolata da leggi e regolamenti. Le informazioni del log devono essere archiviate in modo sicuro e devono essere seguite linee guida appropriate per la loro analisi. L'anonimizzazione delle informazioni personali all'interno delle singole voci aiuta, ma generalmente non è sufficiente per impedire che le tracce del log reali vengano re-identificate in base alla correlazione con altre caratteristiche di accesso. Pertanto, le tracce di accesso associate a un client specifico dovrebbero (ought to) essere anonimizzate o considerate riservate.
Per ridurre al minimo il rischio di furto o pubblicazione accidentale, le informazioni del log dovrebbero (ought to) essere eliminate il prima possibile.
9.5. Divulgazione del frammento dopo i reindirizzamenti (Disclosure of Fragment after Redirects)
Sebbene gli identificatori di frammento utilizzati all'interno dei riferimenti URI non vengano inviati nelle richieste, gli implementatori dovrebbero (ought to) essere consapevoli che saranno visibili all'agente utente e a qualsiasi estensione o script in esecuzione come risultato della risposta. In particolare, quando si verifica un reindirizzamento e l'identificatore di frammento della richiesta originale viene ereditato dal nuovo riferimento in Location (Sezione 7.1.2), ciò potrebbe avere conseguenze sulla sicurezza.
9.6. Divulgazione di informazioni sul prodotto (Disclosure of Product Information)
I campi di intestazione Server e User-Agent rivelano spesso informazioni sui rispettivi sistemi software del mittente. In teoria, ciò può rendere più facile per un attaccante sfruttare falle di sicurezza note; in pratica, gli attaccanti tendono a provare tutti i potenziali buchi indipendentemente dalle versioni software apparenti in uso.
I proxy che fungono da portale attraverso un firewall di rete dovrebbero (ought to) prendere precauzioni speciali riguardo al trasferimento di informazioni di intestazione che potrebbero identificare gli host dietro il firewall. Il campo di intestazione Via consente agli intermediari di sostituire i nomi delle macchine sensibili con pseudonimi.
9.7. Fingerprinting del browser (Browser Fingerprinting)
Il fingerprinting del browser è un insieme di tecniche per identificare un agente utente specifico nel tempo attraverso il suo insieme unico di caratteristiche. Queste caratteristiche potrebbero includere informazioni relative al modo in cui utilizza il protocollo di trasporto sottostante, capacità delle funzionalità e ambiente di scripting, sebbene di particolare interesse qui sia l'insieme di caratteristiche uniche che potrebbero essere comunicate tramite HTTP. Il fingerprinting è considerato un problema di privacy perché consente il tracciamento del comportamento di un agente utente nel tempo (Sezione 9.4) senza i controlli corrispondenti che l'utente potrebbe avere su altre forme di dati, come i cookie.
Ci sono diversi campi di intestazione di richiesta che potrebbero rivelare informazioni ai server sufficientemente uniche da abilitare il fingerprinting. Il campo di intestazione From è il più ovvio, sebbene ci si aspetti che From venga inviato solo quando l'auto-identificazione è desiderata dall'utente. Allo stesso modo, i campi di intestazione Cookie sono deliberatamente progettati per abilitare la re-identificazione, quindi le preoccupazioni di fingerprinting si applicano solo quando i cookie sono disabilitati o limitati dall'agente utente.
Il campo di intestazione User-Agent potrebbe contenere informazioni sufficienti per identificare in modo univoco un dispositivo specifico, di solito quando combinato con altre caratteristiche, in particolare se l'agente utente invia dettagli eccessivi sul sistema dell'utente o sulle estensioni. Tuttavia, la fonte di informazioni uniche meno attesa dagli utenti è la negoziazione proattiva (Sezione 3.4.1), inclusi i campi di intestazione Accept, Accept-Charset, Accept-Encoding e Accept-Language.
Oltre alla preoccupazione del fingerprinting, l'uso dettagliato del campo di intestazione Accept-Language può rivelare informazioni che l'utente potrebbe considerare di natura privata. Ad esempio, la comprensione di un dato insieme di lingue potrebbe essere fortemente correlata all'appartenenza a un particolare gruppo etnico. Un approccio che limita tale perdita di privacy sarebbe per un agente utente omettere l'invio di Accept-Language tranne per i siti che sono stati messi in whitelist, forse tramite interazione dopo aver rilevato un campo di intestazione Vary che indica che la negoziazione della lingua potrebbe essere utile.
Negli ambienti in cui i proxy vengono utilizzati per migliorare la privacy, gli agenti utente dovrebbero (ought to) essere conservativi nell'invio di campi di intestazione di negoziazione proattiva. Gli agenti utente per scopi generali che forniscono un alto grado di configurabilità dei campi di intestazione dovrebbero (ought to) informare gli utenti sulla perdita di privacy che potrebbe derivare se vengono forniti troppi dettagli. Come misura di privacy estrema, i proxy potrebbero filtrare i campi di intestazione di negoziazione proattiva nelle richieste inoltrate.
9.8. Conservazione del validatore (Validator Retention)
I validatori contenuti all'interno dei metadati di risposta (Sezione 7.2) dovrebbero (ought to) essere conservati da una cache solo per il tempo necessario per l'elaborazione normale e la scadenza della risposta memorizzata nella cache. Mantenere i validatori per periodi prolungati può portare a problemi di privacy perché i vecchi validatori potrebbero essere utilizzati per correlare l'attività di un singolo utente attraverso più richieste, anche se il server non associa esplicitamente i valori dei validatori ai singoli utenti. Gli agenti utente che non agiscono come cache non dovrebbero (ought not to) conservare i validatori per periodi prolungati.