Passa al contenuto principale

6. Considerazioni sulla sicurezza

Questa sezione ha lo scopo di informare sviluppatori, fornitori di informazioni e utenti sui problemi di sicurezza noti specifici dell'autenticazione HTTP. Considerazioni di sicurezza più generali sono trattate nella messaggistica HTTP [RFC7230] e nella semantica HTTP [RFC7231].

Tutto ciò che riguarda il tema dell'autenticazione HTTP è una considerazione di sicurezza, pertanto l'elenco di considerazioni che segue non è esaustivo. Inoltre, esso è limitato alle considerazioni di sicurezza riguardanti il framework di autenticazione in generale, anziché discutere tutte le potenziali considerazioni per schemi di autenticazione specifici (che dovrebbero essere documentate nelle specifiche che definiscono tali schemi). Diverse organizzazioni mantengono informazioni tematiche e collegamenti alla ricerca attuale sulla sicurezza delle applicazioni Web (ad esempio [OWASP]), incluse le insidie comuni nell'implementazione e nell'uso degli schemi di autenticazione riscontrati nella pratica.

6.1 Riservatezza delle credenziali​

Il framework di autenticazione HTTP non definisce un singolo meccanismo per mantenere la riservatezza delle credenziali; ciascuno schema di autenticazione definisce invece come le credenziali vengono codificate prima della trasmissione. Se da un lato ciò offre flessibilità per lo sviluppo di futuri schemi di autenticazione, dall'altro è inadeguato per la protezione degli schemi esistenti che di per sé non forniscono alcuna riservatezza, o che non proteggono sufficientemente contro gli attacchi di 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 sottostante a livello di trasporto o di sessione per fornire una trasmissione riservata dei campi di intestazione. In altre parole, se un server limita l'accesso agli utenti autenticati usando questo framework, deve garantire che la connessione sia adeguatamente protetta in conformità con la natura dello schema di autenticazione utilizzato. Ad esempio, i servizi che dipendono dall'autenticazione individuale degli utenti richiedono spesso che la connessione sia protetta con TLS ("Transport Layer Security", [RFC5246]) prima di scambiare qualsiasi credenziale.

6.2 Credenziali di autenticazione e client inattivi​

I client HTTP e gli user agent esistenti conservano tipicamente le informazioni di autenticazione a tempo indefinito. HTTP non fornisce un meccanismo con cui il server di origine possa indicare ai client di eliminare queste credenziali memorizzate nella cache, poiché il protocollo non ha consapevolezza di come le credenziali vengano ottenute o gestite dallo user agent. I meccanismi per far scadere o revocare le credenziali possono essere specificati come parte della definizione di uno schema di autenticazione.

Le circostanze in cui la memorizzazione in cache delle credenziali può interferire con il modello di sicurezza dell'applicazione includono, senza limitarsi a:

  • Client rimasti inattivi per un periodo prolungato, dopo il quale il server potrebbe voler indurre il client a richiedere di nuovo all'utente le credenziali.

  • Applicazioni che includono un'indicazione di fine sessione (come un pulsante "logout" o "commit" su una pagina), dopo la quale il lato server dell'applicazione "sa" che non vi è più motivo per il client di conservare le credenziali.

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

6.3 Spazi di protezione​

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

Questo è particolarmente preoccupante quando un server di origine ospita risorse per più soggetti sotto la stessa URI radice canonica (Sezione 2.2). Le possibili strategie di mitigazione includono limitare l'accesso diretto alle credenziali di autenticazione (cioè non rendere disponibile il contenuto del campo di intestazione di richiesta Authorization) e separare gli spazi di protezione usando un nome host (o numero di porta) diverso per ciascun soggetto.