Cookie-urile terță parte au un viitor incert, dar pot provoca în continuare probleme de confidențialitate pentru utilizatorii neavizați.

De mai mulți ani, susținătorii pentru protecția confidențialității au tras un semnal de alarmă cu privire la utilizarea modulelor cookie pentru a urmări, a stabili profiluri și a furniza reclame personalizate utilizatorilor web. Discuțiile au fost deosebit de aprinse în ceea ce privește  modulele cookie utilizate pentru urmărirea cross-site, situație în care un site web transmite sau oferă date despre vizitatori unor servicii terțe incluse în site.

Ca răspuns, în ultimii doi ani unii dintre principalii dezvoltatori de browsere web și-au intensificat eforturile pentru a oferi opțiuni îmbunătățite sau noi modalități de blocare a modulelor cookie terță parte. În 2020, Apple a actualizat Intelligent Tracking Prevention în Safari și, în 2021, Mozilla a lansat Total Cookie Protection în Firefox pentru a limita urmărirea prin intermediul cookie-urilor terță parte.

Google a mers atât de departe încât a promis că va dezactiva cookie-urile de la terți în Chrome, dar nu până când nu va fi dezvoltată o alternativă de păstrare a confidențialității – care este în prezent explorată în cadrul inițiativei Privacy Sandbox – pentru companiile care au nevoie de servicii de publicitate și analiză.

Cu toate acestea, întreaga serie de eforturi depuse pentru a bloca modulele cookie terță parte poate fi în zadar dacă utilizatorul nu verifică setările browserului ales. Este posibil ca un browser web proaspăt instalat să nu blocheze în mod implicit cookie-urile terților. O excepție notabilă este Firefox pentru desktop, care are setarea Total Cookie Protection activată în mod implicit începând cu iunie 2022.

Pentru a înțelege mai bine preocupările legate de modulele cookie, vom arunca o scurtă privire asupra câmpurilor de antet (header) ale Protocolului de transfer de hipertext (HTTP), apoi vom analiza în profunzime modul în care arată modulele cookie, felul în care acestea sunt gestionate de browserele web și unele dintre implicațiile utilizării lor asupra securității și confidențialității.

De ce folosesc site-urile web cookie-uri?

Site-urile web utilizează HTTP pentru a afișa paginile web solicitate de vizitatori. Folosind acest protocol, un client – de exemplu, un browser web precum Google Chrome – trimite o cerere HTTP către un server, iar serverul transmite înapoi un răspuns HTTP. Rețineți că, în acest articol, folosim “HTTP” pentru a ne referi la HTTP sau HTTPS.

HTTP este un protocol fără stare, ceea ce înseamnă că un server poate procesa cererea fără să depindă de alte cereri. Cu toate acestea, prin utilizarea modulelor cookie, serverele pot menține starea – pot identifica mai multe cereri ca provenind din aceeași sursă în timpul reîncărcărilor de pagină, al navigărilor, al repornirii browserului și chiar în site-urilor terților. Aceasta a fost rațiunea care a stat la baza introducerii modulelor cookie.

Ce sunt câmpurile de antet HTTP?

Fără a intra prea mult în detaliile HTTP, ceea ce este cel mai important de înțeles aici este că o cerere HTTP conține câmpuri de antet care modifică sau transmit informații despre cerere. Să luăm în considerare următoarea cerere a clientului:

Figura 1. O cerere HTTP

Această cerere are două câmpuri de antet: User-Agent și Host.

Câmpul de antet User-Agent indică faptul că clientul care face cererea este Chrome versiunea 103 care rulează pe un computer Windows 10 pe 64 de biți. Rețineți că User-Agent poate fi falsificat. Câmpul de antet Host indică domeniul și, opțional, portul de conectare către care se face solicitarea și este necesar în toate solicitările HTTP v1.1; în acest caz, domeniul este example.com.

Serverul example.com ar putea trimite un răspuns la cererea de mai sus care să arate astfel:

Figura 2. Răspuns HTTP

Un răspuns HTTP conține, de asemenea, câmpuri de antet care modifică răspunsul, iar acest răspuns include chiar și conținutul mesajului. Din nou, ideea principală aici este că cererile și răspunsurile HTTP utilizează câmpuri de antet care afectează procesarea lor prin intermediul informațiilor pe care le furnizează, care pot include cookie-uri.

Ce sunt cookie-urile?

Un modul cookie este o anumită cantitate de date furnizată de un server unui client, de obicei prin intermediul câmpului de antet Set-Cookie, sub forma unei perechi de tip “nume=valoare”. Să refacem răspunsul HTTP de mai sus, dar de data aceasta serverul va încerca să seteze un modul cookie.

Figura 3. Un server poate utiliza câmpul de antet Set-Cookie pentru a trimite cookie-uri către clienți.

În acest exemplu de cookie, SessionID este numele cookie-ului, iar 31d4d96e407aad42 este valoarea cookie-ului.

Unde sunt stocate cookie-urile?

Atunci când un browser Google Chrome care rulează pe Windows primește un răspuns HTTP cu module cookie, acesta salvează modulele cookie pe disc într-o bază de date SQLite versiunea 3 numită Cookies:

Figura 4. Calea către baza de date Chrome Cookies

Această bază de date conține un tabel numit cookies, în care valoarea cookie-ului este criptată și stocată într-o coloană numită encrypted_value, împreună cu metadatele asociate, după cum se poate vedea din celelalte coloane din tabel:

Figura 5. Coloanele din tabelul de module cookie din baza de date Chrome Cookies

Un rând parțial din tabelul de cookie-uri ar putea arăta astfel:

Figura 6. Un rând parțial din tabelul de module cookie din baza de date Chrome Cookies

Instrumentele care încearcă să acceseze baza de date Cookies și să decripteze valorile cookie-urilor pot fi detectate de protecția în timp real a sistemului de fișiere a produselor ESET. De exemplu, acest script Python disponibil în GitHub este detectat ca Python/PSW.Stealer.AD: 

Figura 7. Protecția în timp real a sistemului de fișiere a produselor ESET detectează Python/PSW.Stealer.AD care încearcă să decripteze valorile cookie-urilor

Cu toate acestea, browserul Chrome vă permite să vizualizați valoarea decriptată a cookie-ului în Chrome DevTools:

Figura 8. Panoul Cookie-uri din Chrome DevTools

Chiar dacă este posibil să vizualizați valoarea decriptată a cookie-ului în Chrome DevTools, valoarea poate părea fără sens, deoarece poate fi o valoare unică, aleatorie (de exemplu, un identificator de sesiune) sau poate conține date care au fost criptate și semnate de serverul emitent și, adesea, codificate într-un mod “sigur pentru text”, cum ar fi base64.

Indiferent de tipul de date stocate în cookie, lungimea perechii de cookie-uri în format nume=valoare nu poate depăși 4kb. Probabil de aici provine descrierea populară a cookie-urilor care stochează biți sau bucăți mici de date.

Returnarea cookie-urilor către server

Odată ce un modul cookie este setat, viitoarele cereri ale clientului către serverul care a setat modulul cookie pot include respectivul modul într-un câmp de antet Cookie. Să refacem cererea HTTP de mai sus, dar de data aceasta să includem cookie-ul setat anterior:

Figura 9. Un client utilizează câmpul de antet Cookie pentru a returna un cookie

Unul dintre punctele critice care influențează confidențialitatea și securitatea pe internet este logica de decizie a clientului cu privire la includerea sau nu a cookie-urilor într-o cerere HTTP către serverul de origine. Acest lucru se reduce în mare măsură la faptul că solicitarea este inițiată într-un context de tip first-party pe site-ul care a setat cookie-ul sau într-un context de tip third-party pe un alt site care include resurse de pe site-ul care a setat inițial cookie-ul.

În continuare, să analizăm modul în care caracteristicile de securitate și confidențialitate ale cookie-urilor afectează decizia clientului de a returna cookie-urile.

Securitatea cookie-urilor

Să spunem că vă conectați la contul dvs. pe un site web. Este de așteptat ca serverul să-și amintească faptul că sunteți logat. Astfel, serverul trimite un cookie după ce vă autentificați. Atâta timp cât clientul returnează acel cookie către server în cererile ulterioare, serverul știe că sunteți conectat și nu este nevoie să vă autentificați din nou la fiecare cerere.

Acum, imaginați-vă că un atacator fură cumva acel cookie, spre exemplu prin intermediul unui malware livrat prin e-mail. Deținerea acelui cookie furat este aproape la fel de bună ca și cum ar avea acreditările dvs. de autentificare, deoarece serverul asociază utilizarea acelui cookie cu autentificarea dvs. originală.

Pentru a reduce pericolele legate de un astfel de furt de cookie-uri, serverul poate implementa câteva măsuri.

În primul rând, acest cookie special poate fi setat să expire după o perioadă scurtă de inactivitate. După expirare, un cookie furat devine inutil pentru un hoț, deoarece contul este efectiv deconectat.

În al doilea rând, serverul poate solicita ca orice acțiune critică, cum ar fi resetarea parolei contului sau, de exemplu, transferul unei sume mai mari decât cea nominală într-o aplicație bancară, să fie confirmată cu parola curentă sau cu un alt mecanism, cum ar fi un cod de verificare. Un hoț de cookie-uri nu ar trebui să poată reseta parola sau goli contul dvs. bancar doar cu ajutorul cookie-ului.

În cele din urmă, serverul poate seta acest modul cookie cu cât mai multe atribute pentru o securitate mai strictă, după cum este adecvat pentru scopul cookie-ului. Acest lucru înseamnă utilizarea următoarelor atribute:

• Secure, care instruiește clienții să nu includă cookie-ul în cererile HTTP necriptate [aceasta este o măsură de atenuare a atacurilor de tip adversary-in-the-middle (AitM)];
• HttpOnly, care solicită clienților să împiedice API-urile non-HTTP, cum ar fi JavaScript, să acceseze cookie-ul [aceasta este o măsură de atenuare a atacurilor de scripting cross-site (XSS)];
• SameSite=Strict, care instruiește clienții să includă cookie-ul numai în cererile către domenii care se potrivesc cu site-ul curent afișat în bara de adrese a browserului [aceasta este o măsură de atenuare a atacurilor de falsificare a cererilor încrucișate pe site (CSRF)]; 

și

• Path=/, care solicită clienților să includă cookie-ul în cererile către orice cale a domeniului. În combinație cu următorul punct din această listă, cookie-ul poate fi considerat ca fiind “blocat” pentru respectivul domeniu;
• dar nu și Domain, pentru a împiedica includerea cookie-ului în cererile către subdomenii ale gazdei care a setat cookie-ul. De exemplu, un cookie setat de com nu ar trebui să fie trimis automat către accounts.google.com.

Încercarea de a seta un astfel de cookie fortificat ar arăta în felul următor:

Set-Cookie: SessionID=31d4d4d96e407aad42; Secure; HttpOnly; SameSite=Strict; Path=/

În acest caz, atributele care urmează primei perechi în format nume=valoare fac, de asemenea, parte din cookie.

Luarea de măsuri suplimentare pentru a proteja un site împotriva atacurilor AitM, XSS și CSRF contribuie, de asemenea, la securitatea cookie-urilor și a serviciilor a căror furnizare o susțin.  

Bineînțeles, cookie-urile au mai multe utilizări decât gestionarea utilizatorilor conectați. Ele pot fi folosite și pentru a păstra articole într-un coș de cumpărături, pentru a reține preferințele utilizatorilor și pentru a analiza comportamentul online al acestora.

Cookie-uri primare vs. cookie-uri de la terțe părți

Urmărirea prin intermediul modulelor cookie poate avea loc atât în contextul cookie-urilor first-party (cookie-uri primare), cât și în contextul cookie-urilor third-party (cookie-urile terților). În zilele noastre, urmărirea prin intermediul cookie-urilor first-party este ceva obișnuit, dacă este dezvăluită așa cum cer legile privind confidențialitatea, și nu se pot lua prea multe măsuri împotriva ei, cu excepția, poate, a opțiunii de a bloca toate cookie-urile sau de a le limita prin navigarea în modul privat sau incognito. Astfel veți apărea în evidențe ca un nou vizitator de fiecare dată când vizitați site-ul respectiv, după ce deschideți o fereastră sau o filă nouă și după ce începeți o nouă sesiune de navigare.

Dar ce este mai exact un “cookie first-party”? Să folosim Google ca exemplu. Dacă deschideți https://google.com în browserul dvs. web, atunci toate modulele cookie setate de serverul google.com și care sunt incluse în solicitările clientului (browserului) către google.com sunt considerate module cookie first-party. Un mod simplu de a verifica acest lucru este să căutați cookie-urile cu o valoare a atributului de domeniu de google.com, deoarece acestea corespund domeniului afișat în bara de adrese a browserului.

Chrome DevTools dispune de o bară de instrumente Filters (Filtre) pentru a accelera găsirea cererilor în funcție de proprietatea lor de domeniu și de o filă Cookies (Cookie-uri) pentru a vizualiza cookie-urile trimise cu fiecare cerere:

Figura 10. Cookie-uri first-party returnate către google.com

Și ce este un “cookie third-party”? Dacă vizitați un site care nu aparține Google, cum ar fi welivesecurity.com, care declanșează cereri către google.com – poate că pagina web are un videoclip YouTube încorporat care încarcă un script găzduit pe google.com – cookie-urile incluse în aceste cereri sunt considerate terțe părți. Din nou, o modalitate ușoară de a verifica acest lucru este să căutați cookie-urile cu o valoare a atributului de domeniu de google.com, deoarece acestea nu corespund domeniului afișat în bara de adrese a browserului:

Figura 11. Cookie-uri third-party returnate către google.com

Observați cât de puține cookie-uri sunt returnate către google.com atunci când vizitați acest articol WeLiveSecurity în comparație cu mulțimea de cookie-uri returnate atunci când vizitați direct google.com. Acest lucru se datorează atributului SameSite al cookie-ului. Într-un context terț, numai cookie-urile care sunt setate cu atributele SameSite=None și Secure pot fi returnate.

Acesta este motivul pentru care companiile din domeniul analizei, al publicității și al personalizării sunt foarte interesate de cookie-urile SameSite=None și Secure. Cookie-ul NID al Google, de exemplu, este un super tracker care:

• reține preferințele, cum ar fi limba preferată, numărul de rezultate care trebuie afișate pe o pagină de căutare și dacă filtrul SafeSearch al Google este activat sau nu.
• colectează date analitice privind Google Search.
• afișează anunțurile Google direcționate în serviciile Google pentru utilizatorii care nu sunt conectați.
• permite completarea automată personalizată pe măsură ce utilizatorii introduc termeni de căutare în Google Search.

Cookie-ul NID ar putea dura la nesfârșit – o propunere înfricoșătoare – dacă nu îl ștergeți manual, deoarece este resetat să expire la șase luni după ultima utilizare a unui serviciu Google, de exemplu, și de fiecare dată când vă conectați sau vă deconectați de la contul dvs. Google.

Blocarea modulelor cookie ale terților

Urmărirea parametrilor de autentificare nu va funcționa pe toate site-urile, deoarece exploatează o vulnerabilitate (deși nu toți furnizorii de servicii par să fie preocupați de acest lucru) a modului în care serverul și-a implementat mecanismul de autentificare și modul de gestionare a redirecționărilor. Pentru a preveni urmărirea dvs. pe diferite site-uri web și posibilele scurgeri de informații despre starea dvs. de conectare, asigurați-vă că activați toate setările pe care browserul dvs. le are pentru blocarea modulelor cookie ale terților.

Următoarea listă descrie unde găsiți setările pentru cookie-uri de la terți pentru cele mai populare browsere web.

Firefox

După cum am spus la început, Firefox pentru desktop are activată în mod implicit protecția totală împotriva cookie-urilor încă din iunie 2022. În afară de postarea de pe blog la care tocmai am făcut referire, acest articol oferă un punct de vedere mai aprofundat despre această caracteristică, inclusiv despre cum să remediați afișarea site-urilor care ar putea să nu funcționeze corect având această caracteristică activată. Utilizatorii mai aventuroși ar putea dori să ajusteze setările implicite, care se găsesc aici:

Figura 12. Ajustarea setărilor Firefox pentru o mai bună protecție împotriva urmăririi

Chrome

Browserul Chrome oferă setări pentru modulele cookie în secțiunea “Privacy and security” (Confidențialitate și securitate):

Figura 13. Setarea “Blocați cookie-urile terților” în Chrome

După ce ați bifat opțiunea  “Block third-party cookies” (Blocați modulele cookie de la terți), toate modulele cookie de la terți sunt blocate – acestea nu vor fi returnate către server și nici nu pot fi setate pe client:

Figura 14. Chrome blochează cookie-urile terților

Edge

Pentru browserul Microsoft Edge, urmați pașii indicați în imaginea de mai jos pentru a bloca modulele cookie ale terților:

Figura 15.  Setarea “Block third-party cookies” (Blocați modulele cookie ale terților) din Edge

În setările pentru Safari pe iOS, activați funcția “Prevent Cross-Site Tracking” (Preveniți urmărirea între site-uri):

Safari pe iOS

Figura 16.  Setarea “Prevent Cross-Site Tracking” din Safari iOS

Browsere ale terților pe iOS

iPhone-urile au setarea “Allow Cross-Website Tracking” (Permite urmărirea între site-uri web), disponibilă pentru fiecare browser terț prin intermediul Settings (Setări). Astfel, pe lângă verificarea setărilor cookie-urilor de la terți oferite de fiecare aplicație de browser, asigurați-vă că această setare nu este selectată:

Figura 17.  Setarea “Allow Cross-Website Tracking” din Chrome pe iOS

Concluzie: Se anticipează dispariția cookie-urilor de urmărire ale terților

Cookie-urile de urmărire ale terților sunt pe cale de dispariție. În primul rând, utilizatorii activează tehnologia de blocare a modulelor cookie pe dispozitivele și aplicațiile lor. În al doilea rând, furnizorii de browsere web își consolidează setările implicite ale browserului pentru a limita urmărirea. În al treilea rând, dezvoltatorii web folosesc mecanisme de stocare alternative pentru a gestiona resursele cross-website.

Având în vedere aceste eforturi din ce în ce mai mari de subminare a urmăririi online, cookie-urile de urmărire cross-site se află pe o poziție precară pentru supraviețuirea lor pe termen lung și putem prezice dispariția acestora într-un viitor nu prea îndepărtat.

Sursa: https://blog.eset.ro/how-to/cookie-uri-de-tip-third-party-cum-functioneaza-si-cum-sa-le-impiedicati-sa-va-urmareasca-activitatea-pe-web/