HTTP authentication

HTTP fornisce un framework generico 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 tuo server usando lo schema HTTP "Basic".

Il generico framework di autenticazione HTTP

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

I flussi di challenge e di risposta funzionano in questo modo:

  1. Il server risponde ad un client con una risposta 401 (en-US) (Unauthorized) WWW-Authenticate (en-US) 
  2. Un client vuole autenticarsi con il server, può quindi farlo includendo un request header Authorization con le credenziali
  3. Il client di solito consegna una password prompt all'utente e poi emetterà la richiesta includendo il corretto Authorization header.

A sequence diagram illustrating HTTP messages between a client and a server lifeline.

In caso di un'autenticazione "Basic" mostrata come in figura, lo scambio deve avvenire su una connessione HTTPS per essere sicuro.

Autenticazione proxy

Lo stesso meccanismo di domanda e risposta può essere utilizzato per l'autentificazione del proxy. Poiché sia ​​l'autenticazione delle risorse che l'autenticazione del proxy possono coesistere, è necessaria una nuova impostazione di headers e codici di stato.
Nel caso dei proxy, il codice della challenge è 407(richiesta di autentificazione del proxy), l'intestazione della risposta di autentificazione del proxy cointiene almeno una challenge applicabile al proxy, e l'intestazione della richiesta dell'autentificazione del proxy è utilizzata per fornire le credenziali al server del proxy.

Accesso negato

Se un server(proxy) riceve delle credenziali valide che sono, però, inadeguate per accedere ad una determinata risorsa, il server risponderà con il codice di stato Forbidden 403. A differenza del 401 (non autorizzato) o del 407 (richiesta autentificazione proxy), l'autentificazione è impossibie per questo utente

Autenticazione delle immagini cross-origin

Un potenziale buco di sicurezza risolto recentemente dai browser è l'autenticazione delle immagini cross-site. Da Firefox 59 in avanti, le risorse delle immagini provenienti da origini diverse facenti parte di uno stesso documento non sono più in grado di innescare i dialoghi di autenticazione HTTP (bug 1423146), impedendo che le credenziali degli utenti siano rubate se i malintenzionati fissero in grado di integrare un'immagine casuale in un una immagine di terze parti.

Codifica dei caratteri dell'autenticazione HTTP

I  browsers usano la codifica utf-8 per usarname e password.
Firefox un tempo utilizzava ISO-8859-1, ma ora ha cambiato in utf-8 per essere alla pari con gli altri browsers e per evitare potenziali problemi come descritto nel bug 1419658

Gli header WWW-Authenticate e Proxy-Authenticate

Le risposte del WWW-Authenticate e del Proxy-Authenticate definiscono l'autentificazione dei metodi che può essere utilizzata per guadagnare accessi ad una risorsa. Devono specificare quale schema di autentificazione è stato usato, in modo che il client che desidera autorizzare sa come fornire le credenziali.
La sintassi per questi header è la seguente:

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

Qui, <type>è lo schema di autentificazione ("Basic" è loschema più comune e verrà introdotto sotto). Il realm è usato per descrivere l'area protetta o per indicare l'ambito della protezione. Questo può essere un messaggio del tipo:"Access to the staging site" o cose simili, in modo che l'utente sappia a quale spazio sta cercando di accedere

Gli header Authorization e Proxy-Authorization

I request header Authorization e Proxy-Authorization (en-US) contengono le credenziali per autenticare un utente con un server (proxy). Qui, il <type> dev'essere seguito dalle credenziali, che possono essere codificate o criptate in base a che schema di autenticazione venga usato.

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

Schemi di autenticazione

Il generico framwork di autenticazione HTTP è usato da parecchi schemi di autenticazione. Gli schemi possono differenziare in forza di sicurezza e la loro disponibilità nel software client o server.

Lo schema di autenticazione più comune è lo schema di autenticazione "Basic", il quale sarà introdotto più in dettaglio al di sotto. IANA tiene una lista di schemi di autenticazione, ma ci sono altri schemi offerti dai servizi host, come ad esempio Amazon AWS. I comuni schemi di autenticazione includono:

Basic
Vedi RFC 7617, credenziali codificate in base64. Maggiori informazioni sotto.
Bearer
Vedi RFC 6750, bearer tokens to access OAuth 2.0-protected resources
Digest
Vedi RFC 7616, only md5 hashing is supported in Firefox, see bug 472823 for SHA encryption support
HOBA
Vedi RFC 7486, Section 3, HTTP Origin-Bound Authentication, digital-signature-based
Mutual
Vedi RFC 8120
AWS4-HMAC-SHA256
Vedi AWS docs

Schema di autenticazione di base

Lo schema di autenticazione HTTP "Basic" è definito in RFC 7617, che trasmette le credenziali come user ID/password, codificate usando base64.

Sicurezza dell'autenticazione di base

Siccome l'user ID e la password passano sulla rete come testo (è codificato in base64, ma base64 è una codifica reversibile), lo schema di autenticazione di base non è sicuro. HTTPS/TLS dovrebbero essere usati con l'autenticazione di base. Senza questi aggiuntivi miglioramenti di sicurezza, l'autenticazione di base non dovrebbe essere usata per proteggere dati sensibili o informazioni preziose.

L'accesso ristretto con Apache and l'autenticazione di base

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

il file .htaccess solitamente appare così:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

Il file .htaccess fa riferimento al file .htpasswd nel quale ogni riga è formata da username e password i quali sono separati da due punti (:). Non puoi vedere le password vere siccome vengono codificate (usando MD5-based hashing, in questo caso). Osserva che puoi nominare il tuo file .htpasswd diversamente se vuoi, ma ricordati che il file non dovrebbe essere accessibile a nessuno. (Solitamente Apache è configurato per impedire l'accesso ai file .ht*).

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

L'accesso ristretto con nginx e l'autenticazione di base

Per nginx dovrai specificare un posto che proteggeri e le direttive auth_basic che forniscono il nome all'area protetta dalla password. La direttiva dell'auth_basic_user_file successivamente punterà al file .htpasswd contenente le credenziali dell'utente criptate, come l'esempio Apache sottostante:

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Accesso usando le credenziali nell'URL

Parecchi client evitano il prompt login per mezzo di un URL codificato contenente lo username e la password in questo modo:

https://username:password@www.example.com/

L'uso di questi URL è deprecato. In Chrome, la parte username:password@ dell'URLs è  tolta per motivi di sicurezza. In Firefox, è controllata solo se veramente il sito richiede l'autenticazione, e, se no, Firefox avviserà lo user con un prompt "Stai per loggare nel sito "www.esempio.com" con lo username "username", ma il sito non richiede l'autenticazione. Questo potrebbe essere un tentativo di ingannarti."

Vedi anche