1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
---
title: HTTP authentication
slug: Web/HTTP/Authentication
translation_of: Web/HTTP/Authentication
---
<div>{{HTTPSidebar}}</div>
<p class="summary"><span class="seoSummary">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".</span></p>
<h2 id="Il_generico_framework_di_autenticazione_HTTP">Il generico framework di autenticazione HTTP</h2>
<p>{{RFC("7235")}} definisce il framework di autenticazione HTTP, che può essere usato da un server per {{glossary("challenge")}} una richiesta client, e da un client per fornire informazioni di autenticazione.</p>
<p>I flussi di challenge e di risposta funzionano in questo modo:</p>
<ol>
<li>Il server risponde ad un client con una risposta {{HTTPStatus("401")}} (Unauthorized) {{HTTPHeader("WWW-Authenticate")}} </li>
<li>Un client vuole autenticarsi con il server, può quindi farlo includendo un request header {{HTTPHeader("Authorization")}} con le credenziali</li>
<li>Il client di solito consegna una password prompt all'utente e poi emetterà la richiesta includendo il corretto <code>Authorization</code> header.</li>
</ol>
<p><img alt="A sequence diagram illustrating HTTP messages between a client and a server lifeline." src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;" title="Sequence Diagram of Client-server HTTP Authentication"></p>
<p>In caso di un'autenticazione "Basic" mostrata come in figura, lo scambio deve avvenire su una connessione HTTPS per essere sicuro.</p>
<h3 id="Autenticazione_proxy">Autenticazione proxy</h3>
<p>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.<br>
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.</p>
<h3 id="Accesso_negato">Accesso negato</h3>
<p>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</p>
<h3 id="Autenticazione_delle_immagini_cross-origin">Autenticazione delle immagini cross-origin</h3>
<p>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.</p>
<h3 id="Codifica_dei_caratteri_dellautenticazione_HTTP">Codifica dei caratteri dell'autenticazione HTTP</h3>
<p>I browsers usano la codifica utf-8 per usarname e password.<br>
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</p>
<h3 id="Gli_header_WWW-Authenticate_e_Proxy-Authenticate">Gli header WWW-Authenticate e Proxy-Authenticate</h3>
<p>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.<br>
La sintassi per questi header è la seguente:</p>
<pre class="syntaxbox notranslate">WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>
</pre>
<p>Qui, <code><type></code>è 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</p>
<h3 id="Gli_header_Authorization_e_Proxy-Authorization">Gli header Authorization e Proxy-Authorization</h3>
<p>I request header {{HTTPHeader("Authorization")}} e {{HTTPHeader("Proxy-Authorization")}} contengono le credenziali per autenticare un utente con un server (proxy). Qui, il <code><type></code> dev'essere seguito dalle credenziali, che possono essere codificate o criptate in base a che schema di autenticazione venga usato.</p>
<pre class="syntaxbox notranslate">Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>
</pre>
<h3 id="Schemi_di_autenticazione">Schemi di autenticazione</h3>
<p>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.</p>
<p>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:</p>
<dl>
<dt><strong>Basic</strong></dt>
<dd>Vedi {{rfc(7617)}}, credenziali codificate in base64. Maggiori informazioni sotto.</dd>
<dt><strong>Bearer</strong></dt>
<dd>Vedi {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources</dd>
<dt><strong>Digest</strong></dt>
<dd>Vedi {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support</dd>
<dt><strong>HOBA</strong></dt>
<dd>Vedi {{rfc(7486)}}, Section 3, <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based</dd>
<dt><strong>Mutual</strong></dt>
<dd>Vedi {{rfc(8120)}}</dd>
<dt><strong>AWS4-HMAC-SHA256</strong></dt>
<dd>Vedi <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a></dd>
</dl>
<h2 id="Schema_di_autenticazione_di_base">Schema di autenticazione di base</h2>
<p>Lo schema di autenticazione HTTP "Basic" è definito in {{rfc(7617)}}, che trasmette le credenziali come user ID/password, codificate usando base64.</p>
<h3 id="Sicurezza_dellautenticazione_di_base">Sicurezza dell'autenticazione di base</h3>
<p>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 <strong>non è sicuro</strong>. 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.</p>
<h3 id="Laccesso_ristretto_con_Apache_and_lautenticazione_di_base">L'accesso ristretto con Apache and l'autenticazione di base</h3>
<p>Per proteggere con password una cartella su un server Apapche, avrai bisogno di un file <code>.htaccess</code> e <code>.htpasswd</code> .</p>
<p>il file <code>.htaccess</code> solitamente appare così:</p>
<pre class="notranslate">AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user</pre>
<p>Il file <code>.htaccess</code> fa riferimento al file <code>.htpasswd</code> nel quale ogni riga è formata da username e password i quali sono separati da due punti (<code>:</code>). Non puoi vedere le password vere siccome vengono codificate (usando MD5-based hashing, in questo caso). Osserva che puoi nominare il tuo file <code>.htpasswd</code> diversamente se vuoi, ma ricordati che il file non dovrebbe essere accessibile a nessuno. (Solitamente Apache è configurato per impedire l'accesso ai file <code>.ht*</code>).</p>
<pre class="notranslate">aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
</pre>
<h3 id="Laccesso_ristretto_con_nginx_e_lautenticazione_di_base">L'accesso ristretto con nginx e l'autenticazione di base</h3>
<p>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:</p>
<pre class="notranslate">location /status {
auth_basic "Access to the staging site";
auth_basic_user_file /etc/apache2/.htpasswd;
}</pre>
<h3 id="Accesso_usando_le_credenziali_nellURL">Accesso usando le credenziali nell'URL</h3>
<p>Parecchi client evitano il prompt login per mezzo di un URL codificato contenente lo username e la password in questo modo:</p>
<pre class="example-bad notranslate">https://username:password@www.example.com/</pre>
<p><strong>L'uso di questi URL è deprecato</strong>. In Chrome, la parte <code>username:password@</code> 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."</p>
<h2 id="Vedi_anche">Vedi anche</h2>
<ul>
<li>{{HTTPHeader("WWW-Authenticate")}}</li>
<li>{{HTTPHeader("Authorization")}}</li>
<li>{{HTTPHeader("Proxy-Authorization")}}</li>
<li>{{HTTPHeader("Proxy-Authenticate")}}</li>
<li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
</ul>
|