Traduzione in corso.

HTTP fornisce un framework generico per il controllo degli accessi e l'autenticazione. Lo schema più semplice di autenticazione supportato è il "Basic". In questa pagina sono illustrate le informazioni introduttive al framework di autenticazione e sono spiegate le modalità per implementare lo schema "Basic" per restringere l'accesso al server web.

Il framework generico di autenticazione HTTP

La RFC 7235 definisce il framework di autenticazione che un server può implementare per scatenare la richiesta ad un client oppure implementata da un client per fornire al server le informazioni di autenticazione. Il flusso challenge and response funziona per passi successivi: Il server risponde al client con il codice di stato 401 (Unauthorized) e fornisce informazioni, tramite le informazioni di testata WWW-Authenticate, su come autenticarsi. Il client che desidera autenticarsi con un server può farlo includendo l'informazione Authorization nell'intestazione della richiesta, completo con le credenziali. Generalmente un client richiede le credenziali all'utente tramite una finestra e completa la richiesta con l'intestazione Authorization.

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

Nel caso di utilizzo del metodo di autenticazione "Basic" come mostrato in figura, lo scambio di informazioni, per essere sicuro, deve avvenire all'interno di una connessione protetta HTTPS (TLS).

Autenticazione Proxy

Lo stesso meccanismo di "challenge&response" deve essere utilizzato per l'autenticazione con server proxy. In questo caso, infatti, è il proxy intermedio che richiede l'autenticazione. Nonostante l'autenticazione della risorsa possa coestiste con l'autenticazione proxy, sono necessari due insiemi di codici di stato e intestazioni differenti. Nel caso dei proxy il codice di stato è 407(Proxy Authentication Required), l'intestazione di risposta Proxy-Authenticate contiene almeno una proposta applicabile al proxy e l'intestazione della richiesta Proxy-Authorization è usata per fornire le credenziali al server proxy.

Access forbidden

If a (proxy) server receives valid credentials that are not adequate to gain access for a given resource, the server should respond with the 403 Forbidden status code. Unlike 401 Unauthorized or 407 Proxy Authentication Required, authentication is impossible for this user.

Authentication of cross-origin images

A potential security hole that has recently been fixed by browsers is authentication of cross-site images. From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs (bug 1423146), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.

Character encoding of HTTP authentication

Browsers use utf-8 encoding for usernames and passwords. Firefox used to use  ISO-8859-1, but changed over to utf-8 for parity with other browsers, and to avoid potential problems as described in bug 1419658.

WWW-Authenticate and Proxy-Authenticate headers

The WWW-Authenticate and Proxy-Authenticate response headers define the authentication method that should be used to gain access to a resource. They need to specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials. The syntax for these headers is the following:

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

Here, <type> is the authentication scheme ("Basic" is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.

Authorization and Proxy-Authorization headers

The Authorization and Proxy-Authorization request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

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

Authentication schemes

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

The most common authentication scheme is the "Basic" authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:

  • Basic (see RFC 7617, base64-encoded credentials. See below for more information.),
  • Bearer (see RFC 6750, bearer tokens to access OAuth 2.0-protected resources),
  • Digest (see RFC 7616, only md5 hashing is supported in Firefox, see bug 472823 for SHA encryption support),
  • HOBA (see RFC 7486, Section 3, HTTP Origin-Bound Authentication, digital-signature-based),
  • Mutual (see RFC 8120),
  • AWS4-HMAC-SHA256 (see AWS docs).

Basic authentication scheme

The "Basic" HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.

Security of basic authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Restricting access with Apache and basic authentication

To password-protect a directory on an Apache server, you will need a .htaccess and a .htpasswd file.

The .htaccess file typically looks like this:

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

The .htaccess file references a .htpasswd file in which each line consists of a username and a password separated by a colon (":"). You cannot see the actual passwords as they are encrypted (md5 in this case). Note that you can name your .htpasswd file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to .ht* files).

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

Restricting access with nginx and basic authentication

For nginx, you will need to specify a location that you are going to protect and the auth_basic directive that provides the name to the password-protected area. The auth_basic_user_file directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.

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

Access using credentials in the URL

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:

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

The use of these URLs is deprecated. In Chrome, the username:password@ part in URLs is even stripped out for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you."

Vedere anche

Tag del documento e collaboratori

Hanno collaborato alla realizzazione di questa pagina: robyg72
Ultima modifica di: robyg72,