Autenticazione HTTP

HTTP fornisce un framework generale per il controllo degli accessi e l’autenticazione. Questa pagina è un’introduzione al framework HTTP per l’autenticazione e mostra come limitare l’accesso al server utilizzando lo schema HTTP “Basic”.

Framework generale di autenticazione HTTP

RFC 7235 definisce il framework di autenticazione HTTP, che può essere utilizzato da un server per contestare una richiesta client e da un client per fornire informazioni di autenticazione.

Il flusso di challenge e risposta funziona in questo modo:

Il server risponde a un client con uno stato di risposta 401 (non autorizzato) e fornisce informazioni su come autorizzare con un’intestazione di risposta WWW-Authenticate contenente almeno una contestazione.
Un client che desidera autenticarsi con il server può quindi farlo includendo un’intestazione di richiesta di autorizzazione con le credenziali.
Di solito un client presenterà una richiesta di password all’utente e quindi emetterà la richiesta includendo l’intestazione di autorizzazione corretta.

Il flusso di messaggi generale sopra è lo stesso per la maggior parte (se non tutti) degli schemi di autenticazione. Le informazioni effettive nelle intestazioni e il modo in cui sono codificate cambiano!

Attenzione: lo schema di autenticazione “Base” utilizzato nel diagramma soprastante invia le credenziali codificate ma non crittografate. Ciò sarebbe completamente insicuro a meno che lo scambio non avvenisse tramite una connessione protetta (HTTPS/TLS).

Autenticazione proxy

Lo stesso meccanismo di sfida e risposta può essere utilizzato per l’autenticazione proxy. Poiché sia l’autenticazione delle risorse che l’autenticazione proxy possono coesistere, è necessario un set diverso di intestazioni e codici di stato.

Nel caso dei proxy, il codice di stato di sfida è 407 (Autenticazione proxy richiesta), l’intestazione di risposta Proxy-Authenticate contiene almeno una sfida applicabile al proxy e l’intestazione di richiesta Proxy-Authorization viene utilizzata per fornire le credenziali al server proxy.

Access Forbidden

Se un server (proxy) riceve credenziali non valide, dovrebbe rispondere con un 401 Non autorizzato o con un 407 Autenticazione proxy richiesta e l’utente può inviare una nuova richiesta o sostituire il campo di intestazione Autorizzazione.

Se un server (proxy) riceve credenziali valide che non sono adeguate per accedere a una determinata risorsa, il server dovrebbe rispondere con il codice di stato 403 Forbidden. A differenza di 401 Unauthorized o 407 Proxy Authentication Required, l’autenticazione è impossibile per questo utente e i browser non proporranno un nuovo tentativo.

In tutti i casi, il server potrebbe preferire restituire un codice di stato 404 Not Found, per nascondere l’esistenza della pagina a un utente senza privilegi adeguati o non correttamente autenticato.

Autenticazione di immagini multi-origine

Una potenziale falla di sicurezza (che è stata poi corretta nei browser) era l’autenticazione di immagini multi-sito. Da Firefox 59 in poi, le risorse di immagini caricate da origini diverse al documento corrente non sono più in grado di attivare dialoghi di autenticazione HTTP (bug di Firefox 1423146), impedendo il furto delle credenziali utente se gli aggressori fossero in grado di incorporare un’immagine arbitraria in una pagina di terze parti.

Codifica dei caratteri dell’autenticazione HTTP

I browser utilizzano la codifica utf-8 per nomi utente e password.

Firefox una volta utilizzava ISO-8859-1, ma è passato a utf-8 per parità con altri browser e per evitare potenziali problemi come descritto nel bug 1419658 di Firefox.

Intestazioni WWW-Authenticate e Proxy-Authenticate
Le intestazioni di risposta WWW-Authenticate e Proxy-Authenticate definiscono il metodo di autenticazione che deve essere utilizzato per ottenere l’accesso a una risorsa. Devono specificare quale schema di autenticazione viene utilizzato, in modo che il client che desidera autorizzare sappia come fornire le credenziali.

La sintassi per queste intestazioni è la seguente:

HTTP
WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

Qui, <type> è lo schema di autenticazione (“Basic” è lo schema più comune e introdotto di seguito). Il realm viene utilizzato per descrivere l’area protetta o per indicare l’ambito di protezione. Questo potrebbe essere un messaggio come “Accesso al sito di staging” o simile, in modo che l’utente sappia a quale spazio sta tentando di accedere.

Intestazioni Authorization e Proxy-Authorization

Le intestazioni di richiesta Authorization e Proxy-Authorization contengono le credenziali per autenticare un agente utente con un server (proxy). Qui, è necessario di nuovo <type> seguito dalle credenziali, che possono essere codificate o crittografate a seconda dello schema di autenticazione utilizzato.

HTTP
Copia negli appunti
Authorization: <type> <credenziali>
Proxy-Authorization: <type> <credenziali>

Schemi di autenticazione

Il framework di autenticazione HTTP generale è la base per una serie di schemi di autenticazione.

IANA gestisce un elenco di schemi di autenticazione, ma ci sono altri schemi offerti dai servizi host, come Amazon AWS.

Alcuni schemi di autenticazione comuni includono:

Basic
Vedi RFC 7617, credenziali codificate in base64. Maggiori informazioni di seguito.

Bearer
Vedi RFC 6750, token bearer per accedere alle risorse protette da OAuth 2.0

Digest
Vedi RFC 7616. Firefox 93 e

in seguito supportano l’algoritmo SHA-256. Le versioni precedenti supportano solo l’hashing MD5 (non consigliato).

HOBA
Vedi RFC 7486, Sezione 3, HTTP Origin-Bound Authentication, basata su firma digitale

Mutual
Vedi RFC 8120

Negotiate / NTLM
Vedi RFC4599

VAPID
Vedi RFC 8292

SCRAM
Vedi RFC 7804

AWS4-HMAC-SHA256
Vedi la documentazione AWS. Questo schema è utilizzato per l’autenticazione del server AWS3.

Gli schemi possono differire in termini di sicurezza e disponibilità nel software client o server.

Lo schema di autenticazione “Basic” offre una sicurezza molto scarsa, ma è ampiamente supportato e facile da configurare. È presentato in modo più dettagliato di seguito.

Schema di autenticazione di base

Lo schema di autenticazione HTTP “di base” è definito in RFC 7617, che trasmette le credenziali come coppie ID utente/password, codificate utilizzando base64.

Sicurezza dell’autenticazione di base

Poiché ID utente e password vengono trasmessi sulla rete come testo in chiaro (è codificato in base64, ma base64 è una codifica reversibile), lo schema di autenticazione di base non è sicuro. HTTPS/TLS dovrebbe essere utilizzato con l’autenticazione di base. Senza questi ulteriori miglioramenti della sicurezza, l’autenticazione di base non dovrebbe essere utilizzata per proteggere informazioni sensibili o preziose.

Limitare l’accesso con Apache e l’autenticazione di base

Per proteggere con password una directory su un server Apache, avrai bisogno di un file .htaccess e di un file .htpasswd.

Il file .htaccess in genere si presenta così:

APACHECONF

AuthType Basic
AuthName "Accesso al sito di staging"
AuthUserFile /path/to/.htpasswd
Require valid-user

Il file .htaccess fa riferimento a un file .htpasswd in cui ogni riga è composta da un nome utente e una password separati da due punti (:). Non puoi vedere le password effettive poiché vengono sottoposte a hash (utilizzando l’hashing basato su MD5, in questo caso). Nota che puoi assegnare un nome diverso al tuo file .htpasswd, se preferisci, ma tieni presente che questo file non dovrebbe essere accessibile a nessuno. (Apache è solitamente configurato per impedire l’accesso ai file .ht*).

APACHECONF
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. 
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Limitare l’accesso con Nginx e autenticazione di base

Per Nginx, dovrai specificare una posizione che intendi proteggere e la direttiva auth_basic che fornisce il nome all’area protetta da password. La direttiva auth_basic_user_file punta quindi a un file .htpasswd contenente le credenziali utente crittografate, proprio come nell’esempio di Apache sopra.

APACHECONF
location /status {
auth_basic "Accesso al sito di staging";
auth_basic_user_file /etc/apache2/.htpasswd;
}

Accesso tramite credenziali nell’URL

Molti client ti consentono anche di evitare la richiesta di accesso utilizzando un URL codificato contenente il nome utente e la password in questo modo:

https://username:[email protected]/

L’uso di questi URL è deprecato. In Chrome, la parte username:password@ negli URL viene rimossa dagli URL delle sottorisorse per motivi di sicurezza.

In Firefox, viene verificato se il sito richiede effettivamente l’autenticazione e, in caso contrario, Firefox avviserà l’utente con un messaggio “Stai per accedere al sito www.esempio.com con il nome utente username, ma il sito Web non richiede l’autenticazione.

Questo potrebbe essere un tentativo di ingannarti”. Nel caso in cui il sito richieda l’autenticazione, Firefox chiederà comunque la conferma all’utente “Stai per accedere al sito www.example.com con il nome utente username.” prima di inviare le credenziali al sito.

Nota che Firefox invia la richiesta senza credenziali in entrambi i casi prima di mostrare il messaggio per determinare se il sito richiede l’autenticazione.