17. Security Considerations (Considerazioni sulla sicurezza)

Questa sezione intende informare sviluppatori, fornitori di informazioni e utenti delle problematiche di sicurezza note pertinenti alla semantica HTTP e al suo utilizzo per il trasferimento di informazioni su Internet. Le considerazioni relative al caching sono discusse nella Sezione 7 di [CACHING], e le considerazioni relative alla sintassi e all'analisi dei messaggi HTTP/1.1 sono discusse nella Sezione 11 di [HTTP/1.1].

L'elenco delle considerazioni di seguito non è esaustivo. La maggior parte delle problematiche di sicurezza relative alla semantica HTTP riguarda la sicurezza delle applicazioni server-side (codice dietro l'interfaccia HTTP), la sicurezza della gestione da parte dello user agent del contenuto ricevuto via HTTP o l'uso sicuro di Internet in generale, piuttosto che la sicurezza del protocollo stesso. Le considerazioni sulla sicurezza per gli URI, che sono fondamentali per le operazioni HTTP, sono discusse nella Sezione 7 di [URI]. Diverse organizzazioni mantengono informazioni topiche e collegamenti alla ricerca attuale sulla sicurezza delle applicazioni web (ad esempio, [OWASP]).

17.1. Establishing Authority (Stabilire l'autorità)

HTTP si basa sul concetto di "risposta autoritativa": una risposta che è stata determinata da (o su istruzione di) il server di origine identificato nell'URI di destinazione come la risposta più appropriata per quella richiesta dato lo stato della risorsa di destinazione al momento dell'origine del messaggio di risposta.

Quando un nome registrato viene utilizzato nel componente authority, lo schema URI "http" (Sezione 4.2.1) si basa sul servizio di risoluzione dei nomi locale dell'utente per determinare dove può trovare risposte autoritativ

. Ciò significa che qualsiasi attacco sulla tabella degli host di rete, i nomi memorizzati nella cache o le librerie di risoluzione dei nomi dell'utente diventa un vettore di attacco sull'instaurazione dell'autorità per gli URI "http". Allo stesso modo, la scelta dell'utente del server per il Domain Name Service (DNS), e la gerarchia di server da cui ottiene i risultati della risoluzione, potrebbero influire sull'autenticità dei mapping degli indirizzi; le DNS Security Extensions (DNSSEC, [RFC4033]) sono un modo per migliorare l'autenticità, così come i vari meccanismi per eseguire query DNS su protocolli di trasporto più sicuri.

Inoltre, dopo aver ottenuto un indirizzo IP, l'instaurazione dell'autorità per un URI "http" è vulnerabile agli attacchi sul routing del protocollo Internet.

Lo schema "https" (Sezione 4.2.2) mira a prevenire (o almeno rivelare) molti di questi potenziali attacchi sull'instaurazione dell'autorità, a condizione che la connessione negoziata sia sicura e che il client verifichi correttamente che l'identità del server comunicante corrisponda al componente authority dell'URI di destinazione (Sezione 4.3.4). Implementare correttamente tale verifica può essere difficile (vedere [Georgiev]).

L'autorità per un dato server di origine può essere delegata tramite estensioni del protocollo; ad esempio, [ALTSVC]. Allo stesso modo, l'insieme dei server per cui una connessione è considerata autoritativa può essere modificato con un'estensione del protocollo come [RFC8336].

Fornire una risposta da una fonte non autoritativa, come una cache proxy condivisa, è spesso utile per migliorare le prestazioni e la disponibilità, ma solo nella misura in cui la fonte può essere fidata o la risposta non fidata può essere utilizzata in modo sicuro.

Sfortunatamente, comunicare l'autorità agli utenti può essere difficile. Ad esempio, il "phishing" è un attacco sulla percezione dell'autorità da parte dell'utente, dove tale percezione può essere fuorviata presentando un marchio simile nell'ipertesto, possibilmente aiutato da userinfo che oscurano il componente authority (vedere Sezione 4.2.1). Gli user agent possono ridurre l'impatto degli attacchi di phishing consentendo agli utenti di ispezionare facilmente un URI di destinazione prima di eseguire un'azione, evidenziando in modo prominente (o rifiutando) userinfo quando presente, e non inviando credenziali memorizzate a nessun URI di destinazione che include userinfo.

17.2. Risks of Intermediaries (Rischi degli intermediari)

Gli intermediari HTTP sono intrinsecamente posizionati per attacchi on-path. La compromissione dei sistemi su cui operano gli intermediari può portare a gravi problemi di sicurezza e privacy. Gli intermediari possono avere accesso a informazioni relative alla sicurezza, informazioni personali su singoli utenti e organizzazioni, e informazioni proprietarie appartenenti a utenti e fornitori di contenuti. Un intermediario compromesso, o un intermediario implementato o configurato senza considerare le questioni di sicurezza e privacy, potrebbe essere utilizzato per commettere un'ampia gamma di potenziali attacchi.

Gli intermediari che contengono una cache condivisa sono particolarmente vulnerabili agli attacchi di cache poisoning, come descritto nella Sezione 7 di [CACHING].

Gli implementatori devono considerare le implicazioni sulla privacy e sulla sicurezza delle loro decisioni di progettazione e codifica, e le opzioni di configurazione che offrono agli operatori (in particolare la configurazione predefinita).

Gli intermediari non sono più affidabili delle persone e delle politiche sotto cui operano; HTTP non può risolvere questo problema.

17.3. Attacks Based on File and Path Names (Attacchi basati su nomi di file e percorsi)

I server di origine utilizzano frequentemente il loro file system locale per gestire il mapping 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 il mapping della risorsa di destinazione a file, cartelle o directory.

Ad esempio, UNIX, Microsoft Windows e altri sistemi operativi utilizzano ".." come componente di percorso per indicare un livello di directory superiore a quello corrente, e utilizzano percorsi o nomi di file appositamente nominati per inviare dati ai dispositivi di sistema. Convenzioni di denominazione simili possono esistere in altri tipi di sistemi di archiviazione. Allo stesso modo, i sistemi di archiviazione locali hanno una fastidiosa tendenza a preferire la comodità rispetto alla sicurezza quando gestiscono caratteri non validi o inattesi, ricomposizione di caratteri decomposti e normalizzazione delle maiuscole e minuscole per nomi case-insensitive.

Gli attacchi basati su tali nomi speciali tendono a concentrarsi sul denial-of-service (ad esempio, dire al server di leggere da una porta COM) o sulla divulgazione di file di configurazione e sorgenti che non sono destinati a essere serviti.

17.4. Attacks Based on Command, Code, or Query Injection (Attacchi basati su iniezione di comandi, codice o query)

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 una fonte di dati. Tuttavia, i dati ricevuti in una richiesta non possono essere fidati. Un attaccante potrebbe costruire qualsiasi elemento di dati della richiesta (metodo, URI di destinazione, campi header o contenuto) 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 database.

Ad esempio, l'iniezione SQL è un attacco comune in cui un linguaggio di query aggiuntivo viene inserito in una parte dell'URI di destinazione o dei campi header (ad esempio, Host, Referer, ecc.). Se i dati ricevuti vengono utilizzati direttamente in un'istruzione SELECT, il linguaggio di query potrebbe essere interpretato come comando del database anziché come semplice valore stringa. Questo tipo di vulnerabilità di implementazione è estremamente comune, nonostante sia facile da prevenire.

In generale, le implementazioni delle risorse dovrebbero evitare l'uso di dati della richiesta in contesti che vengono elaborati o interpretati come istruzioni. I parametri dovrebbero essere confrontati con stringhe fisse e agire in base al risultato di tale confronto, piuttosto che essere passati attraverso un'interfaccia che non è preparata per dati non fidati. I dati ricevuti che non sono basati su parametri fissi dovrebbero essere attentamente filtrati o codificati per evitare interpretazioni errate.

Considerazioni simili si applicano ai dati della richiesta quando vengono archiviati ed elaborati successivamente, ad esempio in file di log, strumenti di monitoraggio o quando inclusi in un formato dati che consente script incorporati.

17.5. Attacks via Protocol Element Length (Attacchi tramite lunghezza degli elementi del protocollo)

Poiché HTTP utilizza principalmente campi testuali delimitati da caratteri, i parser sono spesso vulnerabili ad attacchi basati sull'invio di flussi di dati molto lunghi (o molto lenti), in particolare quando un'implementazione si aspetta un elemento del protocollo senza lunghezza predefinita (Sezione 2.3).

Per promuovere l'interoperabilità, vengono fatte raccomandazioni specifiche per i limiti di dimensione minima sui campi (Sezione 5.4). Queste sono raccomandazioni minime, scelte per essere supportabili anche da implementazioni con risorse limitate; ci si aspetta che la maggior parte delle implementazioni scelga limiti sostanzialmente più alti.

Un server può rifiutare un messaggio che ha un URI di destinazione troppo lungo (Sezione 15.5.15) o un contenuto della richiesta troppo grande (Sezione 15.5.14). Codici di stato aggiuntivi relativi ai limiti di capacità sono stati definiti tramite estensioni a HTTP [RFC6585].

I destinatari dovrebbero limitare attentamente la misura in cui elaborano altri elementi del protocollo, inclusi (ma non limitati a) metodi di richiesta, frasi di stato di risposta, nomi di campo, valori numerici e lunghezze dei chunk. Il mancato limite di tale elaborazione può portare all'esecuzione di codice arbitrario a causa di overflow del buffer o aritmetici, e a una maggiore vulnerabilità agli attacchi denial-of-service.

17.6. Attacks Using Shared-Dictionary Compression (Attacchi utilizzando la compressione a dizionario condiviso)

Alcuni attacchi sui protocolli cifrati utilizzano le differenze di dimensione create dalla compressione dinamica per rivelare informazioni riservate; ad esempio, [BREACH]. Questi attacchi si basano sulla creazione di ridondanza tra contenuto controllato dall'attaccante e le informazioni riservate, in modo che un algoritmo di compressione dinamico che utilizza lo stesso dizionario per entrambi i contenuti comprima più efficacemente quando il contenuto controllato dall'attaccante corrisponde a parti del contenuto riservato.

I messaggi HTTP possono essere compressi in vari modi, incluso l'uso della compressione TLS, codifiche di contenuto, codifiche di trasferimento e altri meccanismi di estensione o specifici della versione.

La mitigazione più efficace per questo rischio è disabilitare la compressione sui dati sensibili, o separare rigorosamente i dati sensibili dai dati controllati dall'attaccante in modo che non possano condividere lo stesso dizionario di compressione. Con un design attento, uno schema di compressione può essere progettato in modo da non essere considerato sfruttabile in casi d'uso limitati, come HPACK ([HPACK]).

17.7. Disclosure of Personal Information (Divulgazione di informazioni personali)

I client hanno spesso accesso a grandi quantità di informazioni personali, comprese sia le informazioni fornite dall'utente per interagire con le risorse (ad esempio, nome utente, posizione, indirizzo email, password, chiavi di crittografia, ecc.) sia le informazioni sull'attività di navigazione dell'utente nel tempo (ad esempio, cronologia, segnalibri, ecc.). Le implementazioni devono impedire la divulgazione involontaria di informazioni personali.

17.8. Privacy of Server Log Information (Privacy delle informazioni di log del server)

Un server è in grado di salvare dati personali sulle richieste di un utente nel tempo, che potrebbero identificare i loro modelli di lettura o argomenti di interesse. In particolare, le informazioni di log raccolte presso un intermediario spesso contengono una cronologia dell'interazione dello user agent attraverso una moltitudine di siti, rintracciabile ai singoli utenti.

Le informazioni di log HTTP sono di natura riservata; la loro gestione è spesso vincolata da leggi e regolamenti. Le informazioni di log devono essere archiviate in modo sicuro e devono essere seguite linee guida appropriate per la loro analisi. L'anonimizzazione delle informazioni personali nelle singole voci aiuta, ma generalmente non è sufficiente per impedire che le tracce di log reali vengano re-identificate sulla base della correlazione con altre caratteristiche di accesso. Come tali, le tracce di accesso indicizzate su un client specifico non sono sicure da pubblicare anche se la chiave è pseudonima.

Per minimizzare il rischio di furto o pubblicazione accidentale, le informazioni di log dovrebbero essere epurate da informazioni personalmente identificabili, inclusi ID utente, indirizzi IP e parametri di query forniti dall'utente, non appena tali informazioni non sono più necessarie per supportare le esigenze operative di sicurezza, auditabilità o controllo delle frodi.

17.9. Disclosure of Sensitive Information in URIs (Divulgazione di informazioni sensibili negli URI)

Gli URI sono destinati a essere condivisi, non protetti, anche quando identificano risorse sicure. Gli URI sono spesso mostrati su display, aggiunti ai template quando una pagina viene stampata e archiviati in una varietà di elenchi di segnalibri non protetti. Molti server, proxy e user agent registrano o visualizzano l'URI di destinazione in posti che potrebbero essere visibili a terze parti. Pertanto, è sconsigliato includere informazioni in un URI che siano sensibili, personalmente identificabili o a rischio di divulgazione.

Quando un'applicazione utilizza meccanismi lato client per costruire un URI di destinazione da informazioni fornite dall'utente, come i campi di query di un modulo che utilizza GET, potrebbero essere forniti dati potenzialmente sensibili che sarebbero inappropriati per la divulgazione all'interno di un URI. POST è spesso preferito in tali casi, poiché di solito non costruisce un URI; invece, un POST di un modulo trasmette i dati potenzialmente sensibili nel contenuto della richiesta. Tuttavia, questo ostacola il caching e utilizza un metodo non sicuro per quella che altrimenti sarebbe una richiesta sicura. Soluzioni alternative includono la trasformazione dei dati forniti dall'utente prima di costruire l'URI o il filtraggio dei dati per includere solo valori comuni che non sono sensibili. Allo stesso modo, reindirizzare il risultato di una query a un URI diverso (generato dal server) può rimuovere dati potenzialmente sensibili dai link successivi e fornire una risposta cacheable per un riutilizzo successivo.

Poiché il campo header Referer indica al sito di destinazione il contesto che ha portato alla richiesta, ha il potenziale per rivelare informazioni sulla cronologia di navigazione immediata dell'utente e qualsiasi informazione personale che potrebbe essere trovata nell'URI della risorsa di riferimento. Le limitazioni sul campo header Referer sono descritte nella Sezione 10.1.3 per affrontare alcune delle sue considerazioni sulla sicurezza.

17.10. Application Handling of Field Names (Gestione dei nomi dei campi da parte dell'applicazione)

I server utilizzano spesso interfacce gateway non HTTP e framework per elaborare una richiesta ricevuta e produrre contenuto per la risposta. Per ragioni storiche, tali interfacce spesso passano i nomi dei campi ricevuti come nomi di variabili esterne, utilizzando un mapping di nomi appropriato per le variabili d'ambiente.

Ad esempio, il mapping delle meta-variabili specifiche del protocollo Common Gateway Interface (CGI) definito nella Sezione 4.1.18 di [RFC3875] si applica ai campi header ricevuti che non corrispondono a nessuna delle variabili CGI standard; questo mapping consiste nell'anteporre "HTTP_" a ciascun nome e nel modificare tutte le istanze di trattino ("-") in underscore ("_"). Lo stesso mapping è stato ereditato da molti altri framework applicativi al fine di semplificare lo spostamento delle applicazioni da una piattaforma all'altra.

In CGI, un campo Content-Length ricevuto verrebbe passato come meta-variabile "CONTENT_LENGTH" con un valore stringa corrispondente al valore del campo ricevuto. Al contrario, un campo header "Content_Length" ricevuto verrebbe passato come meta-variabile specifica del protocollo "HTTP_CONTENT_LENGTH", che potrebbe causare qualche confusione se l'applicazione leggesse erroneamente la meta-variabile specifica del protocollo invece di quella predefinita. (Questa pratica storica è il motivo per cui la Sezione 16.3.2.1 sconsiglia la creazione di nuovi nomi di campo contenenti un underscore.)

Sfortunatamente, il mapping dei nomi dei campi a nomi di interfaccia differenti può portare a vulnerabilità di sicurezza se il mapping è incompleto o ambiguo. Ad esempio, se un attaccante dovesse inviare un campo denominato "Transfer_Encoding", un'interfaccia ingenua potrebbe mapparlo allo stesso nome di variabile del campo "Transfer-Encoding", portando a una potenziale vulnerabilità di request smuggling (Sezione 11.2 di [HTTP/1.1]).

Per mitigare i rischi associati, si consiglia alle implementazioni che eseguono tali mapping di rendere il mapping non ambiguo e completo per l'intera gamma di potenziali ottetti ricevuti come nome (inclusi quelli che sono scoraggiati o vietati dalla grammatica HTTP). Ad esempio, un campo con un carattere di nome insolito potrebbe portare al blocco della richiesta, alla rimozione del campo specifico o al passaggio del nome con un prefisso diverso per distinguerlo dagli altri campi.

17.11. Disclosure of Fragment after Redirects (Divulgazione del frammento dopo i reindirizzamenti)

Sebbene gli identificatori di frammento utilizzati nei riferimenti URI non siano inviati nelle richieste, gli implementatori dovrebbero essere consapevoli che saranno visibili allo user agent e a tutte le estensioni 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 10.2.2), ciò potrebbe avere l'effetto di divulgare il frammento di un sito a un altro sito. Se il primo sito utilizza informazioni personali nei frammenti, dovrebbe assicurarsi che i reindirizzamenti ad altri siti includano un componente di frammento (possibilmente vuoto) al fine di bloccare tale eredità.

17.12. Disclosure of Product Information (Divulgazione di informazioni sul prodotto)

I campi header User-Agent (Sezione 10.1.5), Via (Sezione 7.6.3) e Server (Sezione 10.2.4) spesso rivelano informazioni sui rispettivi sistemi software del mittente. In teoria, ciò facilita l'esploitazione da parte di un attaccante di buchi di sicurezza noti; in pratica, gli attaccanti tendono a provare tutti i potenziali buchi indipendentemente dalle versioni software apparentemente utilizzate.

I proxy che fungono da gateway attraverso un firewall di rete dovrebbero prendere precauzioni speciali riguardo all'inoltro di informazioni header che potrebbero identificare host dietro il firewall. Il campo header Via consente agli intermediari di sostituire nomi di macchina sensibili con pseudonimi.

17.13. Browser Fingerprinting (Impronta digitale del browser)

L'impronta digitale del browser è un insieme di tecniche per identificare uno user agent specifico nel tempo attraverso il suo insieme unico di caratteristiche. Queste caratteristiche possono includere informazioni relative a come utilizza il protocollo di trasporto sottostante, capacità delle funzionalità e ambiente di script, sebbene di particolare interesse qui sia l'insieme di caratteristiche uniche che potrebbero essere comunicate tramite HTTP. L'impronta digitale è considerata una preoccupazione per la privacy perché consente di tracciare il comportamento di uno user agent nel tempo ([Bujlow]) senza i controlli corrispondenti che l'utente potrebbe avere su altre forme di raccolta dati (ad esempio, i cookie). Molti user agent general-purpose (cioè, browser web) hanno preso provvedimenti per ridurre la loro impronta.

Ci sono un certo numero di campi header di richiesta che potrebbero rivelare informazioni ai server sufficientemente uniche da consentire l'impronta digitale. Il campo header From è il più ovvio, sebbene ci si aspetti che From sia inviato solo quando l'auto-identificazione è desiderata dall'utente. Allo stesso modo, il campo header Cookie è deliberatamente progettato per consentire la re-identificazione, quindi le preoccupazioni sull'impronta digitale si applicano solo a situazioni in cui i cookie sono disabilitati o limitati dalla configurazione.

Il campo header User-Agent potrebbe contenere informazioni sufficienti per identificare univocamente un dispositivo specifico, di solito quando combinato con altre caratteristiche, in particolare se lo user agent invia dettagli eccessivi sul sistema o sulle estensioni dell'utente. Tuttavia, la fonte di informazioni uniche che la maggior parte degli utenti potrebbe non aspettarsi è la negoziazione proattiva (Sezione 12.1), inclusi i campi header Accept, Accept-Charset, Accept-Encoding e Accept-Language.

Oltre alla preoccupazione per l'impronta digitale, l'uso dettagliato del campo header 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 che gli user agent omettano di inviare Accept-Language tranne che per i siti che sono stati esplicitamente autorizzati, forse tramite interazione dopo aver rilevato un campo header Vary che indica che la negoziazione della lingua potrebbe essere utile.

In ambienti in cui i proxy vengono utilizzati per migliorare la privacy, gli user agent dovrebbero essere conservativi nell'invio di campi header di negoziazione proattiva. Gli user agent general-purpose che offrono un alto grado di configurabilità dei campi header dovrebbero informare gli utenti della perdita di privacy che potrebbe derivare se vengono forniti troppi dettagli. Come misura di privacy estrema, i proxy potrebbero filtrare i campi header di negoziazione proattiva nelle richieste inoltrate.

17.14. Validator Retention (Conservazione dei validatori)

I validatori definiti da questa specifica non sono destinati ad assicurare la validità di una rappresentazione, proteggere contro modifiche dannose o rilevare attacchi on-path. Nel migliore dei casi, consentono aggiornamenti della cache più efficienti e scritture concorrenti ottimistiche quando tutti i partecipanti si comportano correttamente. Nel peggiore dei casi, le condizioni falliranno e il client riceverà una risposta che non è più dannosa di uno scambio HTTP senza richieste condizionali.

Un entity tag può essere abusato in modi che creano rischi per la privacy. Ad esempio, un sito potrebbe deliberatamente costruire un entity tag semanticamente non valido che è unico per l'utente o lo user agent, inviarlo in una risposta cacheable con un tempo di freschezza lungo, e poi leggere quell'entity tag nelle richieste condizionali successive come mezzo per re-identificare quell'utente o user agent. Tale tag identificativo diventerebbe un identificatore persistente finché lo user agent conserva la voce di cache originale. Gli user agent che memorizzano nella cache le rappresentazioni dovrebbero assicurarsi che la cache sia cancellata o sostituita ogni volta che l'utente esegue azioni di mantenimento della privacy, come cancellare i cookie memorizzati o passare a una modalità di navigazione privata.

17.15. Denial-of-Service Attacks Using Range (Attacchi denial-of-service utilizzando Range)

Le richieste di range multipli non vincolati sono suscettibili ad attacchi denial-of-service perché lo sforzo richiesto per richiedere molti range sovrapposti degli stessi dati è minuscolo rispetto al tempo, memoria e larghezza di banda consumati nel tentativo di servire i dati richiesti in molte parti. I server dovrebbero ignorare, unire o rifiutare richieste di range oltraggiose, come richieste per più di due range sovrapposti o per molti range piccoli in un singolo insieme, in particolare quando i range sono richiesti fuori ordine senza ragione apparente. Le richieste di range multipart non sono progettate per supportare l'accesso casuale.

17.16. Authentication Considerations (Considerazioni sull'autenticazione)

Tutto ciò che riguarda l'autenticazione HTTP è una considerazione sulla sicurezza, quindi l'elenco delle considerazioni di seguito non è esaustivo. Inoltre, è limitato alle considerazioni sulla sicurezza riguardanti il framework di autenticazione, in generale, piuttosto che discutere tutte le potenziali considerazioni per schemi di autenticazione specifici (che dovrebbero essere documentate nelle specifiche che definiscono tali schemi). Diverse organizzazioni mantengono informazioni topiche e collegamenti alla ricerca attuale sulla sicurezza delle applicazioni web (ad esempio, [OWASP]), incluse le trappole comuni per l'implementazione e l'utilizzo degli schemi di autenticazione trovati nella pratica.

17.16.1. Confidentiality of Credentials (Riservatezza delle credenziali)

Il framework di autenticazione HTTP non definisce un unico meccanismo per mantenere la riservatezza delle credenziali; invece, ogni schema di autenticazione definisce come le credenziali vengono codificate prima della trasmissione. Sebbene ciò fornisca flessibilità per lo sviluppo di futuri schemi di autenticazione, è inadeguato per la protezione di schemi esistenti che non forniscono alcuna riservatezza da soli, o che non proteggono sufficientemente contro attacchi replay. Inoltre, se il server si aspetta credenziali specifiche per ogni singolo utente, lo scambio di tali credenziali avrà l'effetto di identificare quell'utente anche se il contenuto delle credenziali rimane riservato.

HTTP dipende dalle proprietà di sicurezza della connessione a livello di trasporto o sessione sottostante per fornire trasmissione riservata dei campi. I servizi che dipendono dall'autenticazione utente individuale richiedono una connessione protetta prima di scambiare credenziali (Sezione 4.2.2).

17.16.2. Credentials and Idle Clients (Credenziali e client inattivi)

I client HTTP e gli user agent esistenti tipicamente conservano le informazioni di autenticazione indefinitamente. HTTP non fornisce un meccanismo per il server di origine per ordinare ai client di scartare queste credenziali memorizzate nella cache, poiché il protocollo non ha conoscenza di come le credenziali vengono ottenute o gestite dallo user agent. I meccanismi per la scadenza o revoca delle credenziali possono essere specificati come parte di una definizione dello schema di autenticazione.

Le circostanze in cui la memorizzazione nella cache delle credenziali può interferire con il modello di sicurezza dell'applicazione includono, ma non sono limitate a:

• Macchine client lasciate inattive, incustodite dall'utente, dopo di che il server potrebbe desiderare causare al client di richiedere nuovamente le credenziali all'utente.

• Applicazioni che includono un'indicazione di termine della sessione (come un pulsante "logout" o "submit" su una pagina) dopo di che il lato server dell'applicazione "sa" che non c'è più motivo per il client di conservare le credenziali.

Gli user agent che memorizzano nella cache le credenziali sono incoraggiati a fornire un meccanismo facilmente accessibile per scartare le credenziali memorizzate nella cache sotto il controllo dell'utente.

17.16.3. Protection Spaces (Spazi di protezione)

Gli schemi di autenticazione che si basano esclusivamente sul meccanismo "realm" per stabilire uno spazio di protezione esporranno le credenziali a tutte le risorse su un server di origine. I client che hanno effettuato con successo richieste autenticate con una risorsa possono utilizzare le stesse credenziali di autenticazione per altre risorse sullo stesso server di origine. Ciò consente a una risorsa diversa di raccogliere credenziali di autenticazione per altre risorse.

Questo è di particolare preoccupazione quando un server di origine ospita risorse per più parti sotto la stessa origine (Sezione 11.5). Possibili strategie di mitigazione includono la restrizione dell'accesso diretto alle credenziali di autenticazione (cioè, non rendere disponibile il contenuto del campo header della richiesta Authorization), e la separazione degli spazi di protezione utilizzando un nome host differente (o numero di porta) per ciascuna parte.

17.16.4. Additional Response Fields (Campi di risposta aggiuntivi)

L'aggiunta di informazioni alle risposte inviate su una connessione non cifrata può divulgare sicurezza e privacy. La sola presenza dei campi header Authentication-Info e Proxy-Authentication-Info indica che viene utilizzata l'autenticazione HTTP. Informazioni aggiuntive potrebbero essere esposte dal contenuto dei parametri specifici dello schema di autenticazione; questo dovrà essere considerato nelle definizioni di tali schemi.