Kaka

Cookies ( engelska  cookie , lit. - "cookie") - en liten bit data som skickas av en webbserver och lagras på användarens dator . Webbklienten (vanligtvis en webbläsare ) skickar denna del av data till webbservern som en del av en HTTP -förfrågan när den försöker öppna en sida på motsvarande webbplats . Det används för att spara data på användarsidan, i praktiken används det vanligtvis för [1] :

Webbläsarstöd för cookies (acceptans, lagring och efterföljande överföring av lagrade cookies till servern) krävs av många webbplatser med åtkomstbegränsningar, de flesta onlinebutiker [2] . Att anpassa designen och beteendet hos många webbplatser efter individuella användarpreferenser baseras också på cookies [1] .

Cookies är lätta att fånga upp och förfalska (till exempel för att få tillgång till ett konto) om användaren använder en okrypterad anslutning till servern. I riskzonen är användare som ansluter till Internet med offentliga Wi-Fi- åtkomstpunkter och inte använder mekanismer som SSL och TLS . Kryptering löser även andra problem relaterade till säkerheten för överförda data.

De flesta moderna webbläsare tillåter användare att välja om de vill acceptera cookies eller inte, men om du inaktiverar dem blir vissa webbplatser oanvändbara. Dessutom, enligt lagarna i vissa länder (till exempel enligt förordningen från Europeiska unionen från 2016, se den allmänna dataskyddsförordningen ), måste webbplatser begära användarens samtycke innan en cookie ställs in.

Utnämning

Cookies används av webbservrar för att identifiera användare och lagra data om dem.

Till exempel, om webbplatsen är inloggad med hjälp av cookies, sedan, efter att användaren anger sina uppgifter på inloggningssidan, tillåter cookies servern att komma ihåg att användaren redan har identifierats och får tillgång till relevanta tjänster och operationer [1 ] .

Många webbplatser använder också cookies för att spara användarinställningar. Dessa inställningar kan användas för personalisering, vilket inkluderar val av utseende och funktionalitet. Till exempel tillåter Wikipedia behöriga användare att välja utformningen av webbplatsen. Googles sökmotor tillåter användare (inklusive de som inte är registrerade på den) att välja hur många sökresultat som ska visas på en sida [3] .

Cookies används också för att spåra användaraktivitet på webbplatsen. I regel görs detta i syfte att samla in statistik och reklamföretag, baserat på sådan statistik, bildar anonyma användarprofiler för mer korrekt inriktning av annonsering [4] .

Koncept

Tekniskt sett är cookies bitar av data som initialt skickas av en webbserver till en webbläsare. Vid varje efterföljande besök på webbplatsen skickar webbläsaren dem tillbaka till servern. Utan en cookie är varje webbsidesvy en isolerad åtgärd, som inte är relaterad till att surfa på andra sidor på samma webbplats, med samma cookie kan du identifiera förhållandet mellan att titta på olika sidor. Förutom att skickas av en webbserver kan cookies skapas av skriptspråk som JavaScript om de stöds och aktiveras i webbläsaren.

Specifikationer [5] [6] anger de minimibelopp som webbläsare måste tillhandahålla för att lagra cookies. Således måste webbläsaren lagra minst 300 cookies på vardera 4096 byte och minst 20 cookies per server eller domän .

Populära webbläsare har ett motsvarande maximalt antal lagrade cookies för varje domän:

I praktiken kan vissa webbläsare införa mer restriktiva begränsningar. Till exempel tillhandahåller Internet Explorer 4096 byte för alla cookies på samma domän.

Cookienamn är skiftlägesokänsliga enligt avsnitt 3.1 i RFC 2965 .

Cookies kan ställa in datumet för deras radering, i vilket fall de kommer att raderas automatiskt av webbläsaren inom den angivna perioden. Om inget raderingsdatum anges raderas cookies så snart användaren stänger webbläsaren. Genom att ange ett utgångsdatum kan cookies lagras i mer än en session, och sådana cookies kallas beständiga. En nätbutik kan till exempel använda beständiga cookies för att lagra koderna för varor som användaren har lagt i kundvagnen – och även om användaren stänger webbläsaren utan att göra ett köp kommer de inte att ha nästa gång de loggar in att bygga om vagnen.

Cookielagring kan också vara begränsad beroende på webbservern, domänen eller underdomänen där de skapades.

Historik

Enligt en version kommer termen "cookies" (cookies) från " magiska cookies " [7]  - en uppsättning data som programmet tar emot och sedan skickar tillbaka oförändrat. I juni 1994 kom Lou Montulli på idén att använda dem i en webbanslutning [8] . Då var han anställd på Netscape Communications , som höll på att utveckla ett beställt e-handelspaket. Cookies har blivit en lösning på problemet med tillförlitlig implementering av den virtuella kundvagnen.

Med hjälp av John Giannandrea skrev Montulli den första cookiespecifikationen samma år. Mosaic Netscape 0.9beta, släppt 13 oktober 1994 [9] [10] , stödde redan cookies. Cookies användes först utanför labbet på Netscape-webbplatsen och avgjorde om en användare tidigare hade besökt webbplatsen. Montulli ansökte om patent 1995 och fick det 1998. Internet Explorer började stödja cookies med version 2, släppt i oktober 1995 [11] .

Även om vissa personer var medvetna om förekomsten av cookies redan under första kvartalet 1995 [12] blev allmänheten inte medveten om dem förrän efter en artikel i Financial Times den 12 februari 1996 . Samma år blev cookies i fokus för mediauppmärksamhet, särskilt på grund av det potentiella hotet mot integriteten . Cookies övervägdes av US Federal Trade Commission i två utfrågningar 1996 och 1997.

Utvecklingen av cookie-specifikationer stannade inte där. I synnerhet började de första diskussionerna om en formell specifikation i april 1995. En ad hoc-arbetsgrupp inom IETF har bildats . Netscape-specifikationen valdes som utgångspunkt. I februari 1996 identifierade en arbetsgrupp cookies från tredje part som ett allvarligt integritetshot. Den resulterande specifikationen släpptes som RFC 2109 i februari 1997 . Den angav att tredjepartscookies antingen skulle blockeras eller åtminstone inte fungera som standard.

På den tiden använde reklamföretag redan tredjepartscookies med might och main, och RFC 2109- rekommendationer stöddes inte av varken Netscape-webbläsare eller Internet Explorer. Senare, i oktober 2000 , ersattes RFC 2109 av den nya RFC 2965- specifikationen .

Cookie typer

Sessionscookies

Sessionscookies , även känd som temporära cookies , finns bara i det tillfälliga minnet när användaren är på en sida på en webbplats. Webbläsare tar vanligtvis bort sessionscookies efter att användaren stänger webbläsarfönstret [13] . Till skillnad från andra typer av cookies har sessionscookies inget utgångsdatum och tolkas därför av webbläsare som sessionscookies.

Beständiga cookies

Istället för att raderas när webbläsaren är stängd, som sessionscookies gör, raderas persistenta cookies vid ett visst datum eller efter en viss tidsperiod. Detta innebär att information om cookien kommer att skickas till servern varje gång användaren besöker webbplatsen som cookien tillhör. Av denna anledning kallas beständiga cookies ibland som spårningscookies eftersom de kan användas av annonsörer för att registrera användarpreferenser under en längre tidsperiod. De kan dock också användas för "fredliga" syften, till exempel för att undvika att mata in data igen varje gång du besöker sidan.

Tredjepartscookies

Vanligtvis är domänattributet för en cookie detsamma som den domän som visas i adressfältet i en webbläsare. Detta kallas den första kakan. Tredjepartscookien tillhör dock en annan domän än den som anges i adressfältet. Denna typ av kaka visas vanligtvis när webbsidor innehåller innehåll från externa webbplatser, till exempel bannerannonser. Detta öppnar upp möjligheter att spåra en användares webbhistorik och används ofta av annonsörer för att tillhandahålla relevanta annonser till varje användare.

Anta som ett exempel att en användare besöker www.example.org. Denna webbplats innehåller annonser från ad.foxytracking.com som, när den laddas, placerar en cookie som tillhör annonsdomänen (ad.foxytracking.com). Användaren besöker sedan en annan webbplats www.foo.com som också innehåller annonser från ad.foxytracking.com och sätter en cookie som tillhör den domänen (ad.foxytracking.com). När allt kommer omkring kommer båda dessa cookies att skickas till annonsören när deras annons laddas eller deras webbplats besöks. Annonsören kan sedan använda dessa cookies för att bygga upp användarens webbhistorik på alla webbplatser som är värd för annonsörens annons.

Från och med 2014 satte vissa webbplatser läscookies på över 100 tredjepartsdomäner [14] . I genomsnitt sattes 10 cookies per webbplats, där det maximala antalet cookies (för både tredje part och tredje part) översteg 800 [15] . De flesta moderna webbläsare innehåller sekretessinställningar som kan blockera cookies från tredje part.

Supercookie

En supercookie är en cookie med ett toppdomänursprung (t.ex. .ru ) eller ett offentligt suffix (t.ex. .co.uk). Vanliga cookies, å andra sidan, härleds från ett specifikt domännamn, som exempel.com.

Supercookies kan vara ett potentiellt säkerhetsproblem och blockeras därför ofta av webbläsare. Om en webbläsare avblockerar en skadlig webbplats kan en angripare ställa in en supercookie och potentiellt störa eller imitera legitima användarförfrågningar till en annan webbplats som använder samma toppdomän eller offentliga suffix som den skadliga webbplatsen. Till exempel kan en supercookie med origin .com med skadlig uppsåt påverka en begäran till example.com även om cookien inte skapades från example.com. Detta kan användas för att fejka inloggningar eller ändra användarinformation.

Den offentliga listan med suffix [16] hjälper till att minska risken för att supercookies utgör. Public Suffix List är ett initiativ för flera leverantörer som syftar till att tillhandahålla en korrekt och uppdaterad lista över domännamnssuffix. Äldre versioner av webbläsare kanske inte har en uppdaterad lista och är därför sårbara för supercookies från vissa domäner.

Termen "supercookie" (supercookie) används ibland för att spåra tekniker som inte använder HTTP-cookies. I augusti 2011 upptäcktes två sådana "supercookie"-mekanismer på Microsofts webbplatser: cookie-synkronisering, som producerar en MUID-cookie (unique machine identifier) ​​och en ETag-cookie [17] . På grund av mediauppmärksamhet inaktiverade Microsoft senare denna kod [18] .

Zombie cookies

Eftersom cookies mycket enkelt kan tas bort från webbläsaren, letar programmerare efter sätt att identifiera användare även efter att ha rensat webbläsarens historik helt. En sådan lösning är zombie-cookies (eller evercookie , eller persistent cookies ) - cookies som inte går att radera eller som är svåra att ta bort som kan återställas i webbläsaren med hjälp av JavaScript. Detta är möjligt eftersom webbplatsen samtidigt använder alla tillgängliga webbläsarlagringar för att lagra cookies ( HTTP ETag, Session Storage, Local Storage, Indexed DB ), inklusive applikationslagringar som Flash Player ( Local Shared Objects ), Microsoft Silverlight ( Isolated Storage ) och Java ( Java persistence API ). När programmet upptäcker frånvaron av en cookie i webbläsaren, information om vilken finns i andra butiker, återställer det omedelbart den till sin plats och identifierar därigenom användaren för webbplatsen.

Cookie-alternativ

RFC 6265 ger specifika instruktioner om hur man tolkar var och en av cookieparametrarna:

Under 2015 godkändes ett dokument som uppdaterade RFC 6265- specifikationen , som lade till en uppsättning namnbegränsningar för cookies. För att ge ytterligare säkerhet har experter föreslagit speciella namnprefix __Secure-och __Host-, vilket indikerar för webbläsaren behovet av att uppfylla särskilda krav när de tar emot cookies från servern [19] .

Om minst ett av de angivna kraven överträds, kommer installationen av en cookie i webbläsaren att avvisas. Prefixstöd är implementerat i Chrome 49+, Firefox 50+ och Opera 36+ [20] .

Om alla ovanstående alternativ är aktiverade kommer begäran att ställa in en cookie från servern se ut så här:

Set-Cookie: __Secure-name=value; max-age=31536000; domain=example.com; path=/; secure; httponly; samesite=lax

Hur cookies fungerar

Precis som alla andra HTTP-rubriker måste en cookie skickas till webbläsaren innan någon annan data skickas, inklusive tomma strängar och blanksteg (detta är en begränsning av HTTP-protokollet).

Ställa in en cookie

När du begär en sida skickar webbläsaren en kort text med en HTTP-förfrågan till webbservern. Till exempel, för att komma åt sidan http://www.example.org/index.html skickar webbläsaren följande begäran till www.example.org-servern:1

GET /index.html HTTP/1.1
Värd: www.example.org
5

webbläsare server

Servern svarar genom att skicka den begärda sidan tillsammans med en text som innehåller ett HTTP-svar. Den kan innehålla en instruktion till webbläsaren att spara cookien:

HTTP/1.1 200 OK
Innehållstyp: text/html
Set-Cookie: namn=värde
 
(sidinnehåll)

webbläsare server

Strängen Set-cookieskickas endast när servern vill att webbläsaren ska spara kakan. I det här fallet, om cookies stöds av webbläsaren och deras acceptans är aktiverat, kommer webbläsaren ihåg strängen name=value(namn = värde) och skickar tillbaka den till servern med varje efterföljande begäran. Till exempel, när du begär följande sida http://www.example.org/spec.html, skickar webbläsaren följande begäran till www.examle.org-servern:

GET /spec.html HTTP/1.1
Värd: www.example.org
Cookie: namn=värde
Acceptera: */*
 

webbläsare server

Denna begäran skiljer sig från den första begäran genom att den innehåller strängen som servern skickade till webbläsaren tidigare. Således kommer servern att veta att denna begäran är relaterad till den föregående. Servern svarar genom att skicka den begärda sidan och eventuellt lägga till nya cookies.

Cookievärdet kan ändras av servern genom att skicka nya rader Set-Cookie: name=new_value. Webbläsaren ersätter sedan den gamla cookien med samma namn med den nya strängen.

Cookies kan också ställas in av program på språk som JavaScript, inbäddade i texten på sidor eller liknande skript som körs i webbläsaren. JavaScript använder cookie-egenskapen för dokumentobjektet för att göra detta document.cookie. Till exempel kommer den document.cookie="temperature=20"att skapa en cookie som kallas "temperatur" med ett värde på 20 [21] .

Autentisering

Cookies kan användas av servern för att identifiera tidigare autentiserade användare. Det händer så här [22] :

  1. Användaren anger ett användarnamn och lösenord i textfälten på inloggningssidan och skickar dem till servern.
  2. Servern tar emot användarnamnet och lösenordet, kontrollerar dem och, om de är korrekta, skickar en framgångsrik inloggningssida, bifogar en cookie med något sessions-ID. Denna cookie kan vara giltig inte bara för den aktuella webbläsarsessionen, utan kan också ställas in för att lagras under lång tid.
  3. Varje gång en användare begär en sida från servern skickar webbläsaren automatiskt en sessions-ID-cookie till servern. Servern kontrollerar identifieraren mot sin databas med identifierare och, om det finns en sådan identifierare i databasen, "känner" igen användaren.

Denna metod används ofta på många webbplatser som Yahoo! , på Wikipedia och på Facebook .

Många webbläsare (särskilt Opera, FireFox) kan styra webbplatsernas beteende genom att redigera cookieegenskaper. Genom att ändra utgångsdatumet för icke-beständiga (sessions)cookies kan du till exempel få en formellt obegränsad session efter auktorisering på en webbplats. Möjligheten att redigera cookies med standardverktyg är inte tillgänglig i Internet Explorer. Men med hjälp av andra mekanismer, såsom JavaScript, kan användaren ändra cookien. Dessutom är det möjligt att ersätta sessionscookies med permanenta (med utgångsdatum).

Serverprogramvaran kan dock spåra sådana försök. För att göra detta utfärdar servern en cookie under en viss tidsperiod och skriver cookiens utgångsdatum på sig själv eller, i krypterad form, i själva cookies, varje gång användaren går in på servern. Om cookien som skickas av webbläsaren har ett annat utgångsdatum än det som lagras på servern eller som finns i cookien, görs ett försök att förfalska cookiens utgångsdatum. Servern kan svara, till exempel genom att be användaren att återauktorisera.

Webbläsarinställningar

De flesta moderna webbläsare stöder cookies [23] och som regel kan användaren välja om cookies ska användas eller inte. De vanligaste webbläsarinställningarna är [24] :

  1. Inaktivera cookies helt.
  2. Radera cookies när webbläsaren är stängd.
  3. Att skilja tredjepartscookies från en tredje part och behandla dem därefter (till exempel begränsa eller blockera dem).
  4. Cookiebehandling baserad på "vita" och/eller "svarta" listor uppdaterade av användaren eller webbläsartillverkaren. Cookies från den "svarta listan" är blockerade.
  5. Förbud mot cookies från vissa domäner (en sorts "svart lista").
  6. Ange rimliga utgångsdatum för cookies.

De flesta JavaScript-aktiverade webbläsare tillåter användaren att se aktiva cookies på en given webbplats genom att skriva javascript:alert(document.cookie)eller javascript:prompt(document.cookie)i webbläsarens adressfält [24] . Vissa webbläsare inkluderar en cookie-hanterare som tillåter användaren att selektivt visa och radera cookies lagrade i webbläsaren.

Sekretess och tredjepartscookies

Det finns en missuppfattning att cookies är program och kan spåra användaråtgärder oberoende av varandra, även om dessa endast är data som lagras på datorn av webbläsaren [25] . Enligt en undersökning gjord av det amerikanska företaget Insight Express 2005 är 25 % av de tillfrågade säkra på detta [26] .

Cookies har en betydande inverkan på internetanvändarnas anonymitet och användarinformationens integritet . Även om cookies endast skickas till servrar på den domän de är avsedda för, kan en webbsida ladda bilder eller andra komponenter från andra domäner. Cookies som tas emot under laddningen av dessa komponenter från andra domäner kallas "tredje part" [27] .

Annonsföretag använder tredjepartscookies för att spåra användarens rörelser på sajterna. I synnerhet kan ett reklamföretag spåra användare på alla webbplatser där deras reklambanners är installerade . Genom att känna till de sidor som användaren besöker kan du ändra riktningen för reklam beroende på användarens preferenser.

Användarprofilering ses som en potentiell integritetsrisk även när den spåras över en enskild domän, men särskilt när den spåras över flera domäner med hjälp av tredjepartscookies. Av denna anledning är cookies reglerade i lag i vissa länder.

USA:s regering antog strikta lagar om kakor år 2000 efter att det visade sig att den amerikanska narkotikamyndigheten använde cookies för att spåra användare som tittade på deras anti-drogannonser online. 2002 upptäckte Daniel Brandt att CIA satte beständiga cookies på datorer med en lagringstid på upp till 2010. När CIA blev medveten om den illegala användningen av cookies sa byrån att det var oavsiktligt och slutade installera dem [28] . Den 25 december 2005 upptäckte Brandt att National Security Agency lämnade ett par bestående cookies efter en mjukvaruuppdatering. Efter detta meddelande inaktiverade byrån omedelbart cookies [29] .

Europeiska unionens direktiv 2002/58/EG om integritet och elektronisk kommunikation [30] innehåller regler om användningen av cookies. I synnerhet anger artikel 5.3 att lagring av data (inklusive cookies) endast kan ske om:

2009 ändrade direktiv 2009/136/EG [31] direktiv 2002/58/EG, som trädde i kraft i maj 2011. Förändringarna skärpte kraven för att samla in information om webbplatsbesökare. Enligt de nya reglerna måste webbplatsägare erhålla besökarnas förhandsgodkännande till insamling av information (inklusive cookies) och rapportera om de verktyg för informationsinsamling som finns på webbplatsen [32] .

I maj 2018 trädde den allmänna dataskyddsförordningen i kraft i Europeiska unionen , och ersätter det nuvarande direktivet 2002/58/EC, som gäller alla webbplatser som besöks inifrån Europeiska unionen och likställer de flesta cookies med andra personuppgifter. Det ursprungliga utkastet föreslog att webbläsarinställningar kunde anses vara tillräckliga bevis på användarens samtycke till att sätta en cookie [33] , och enligt den slutliga versionen räcker det med meddelanden om inställningen av en cookie [34] .

P3P - specifikationen inkluderar möjligheten för en webbserver att rapportera en integritetsintrång till en webbläsare, vilket anger typen av information som samlas in och syftet med insamlingen. Detta inkluderar användningen av information som erhållits genom cookies. Enligt P3P-specifikationen kan webbläsaren acceptera eller avvisa cookies enligt användarens preferenser eller fråga användaren.

Många webbläsare, inklusive Apples Safari och Microsofts Internet Explorer version 6 och 7, stöder P3P-specifikationer som låter dig avgöra om tredjepartscookies ska tillåtas. Opera - webbläsaren tillåter användare att välja bort cookies från tredje part och skapa globala eller anpassade säkerhetsprofiler för webbdomäner [35] . Firefox 2 tog bort det här alternativet, men det återställdes i version 3.

Nackdelar med cookies

Förutom integritetsfrågor har cookies vissa tekniska nackdelar som är inneboende i all data. I synnerhet identifierar de inte alltid användaren korrekt och kan vara orsaken till skadliga attacker.

Felaktig identifiering

Om mer än en webbläsare används på en dator har var och en vanligtvis en separat cookie-butik. Därför identifierar cookies inte en person, utan en kombination av konto , dator och webbläsare. Således har varje person som använder flera konton, datorer eller webbläsare flera uppsättningar av cookies.

Cookie stöld

Under normal drift utbyts cookies ständigt mellan servern och användarens webbläsare. Eftersom cookies kan innehålla känslig information (användarnamn, åtkomstvillkor etc.) bör deras innehåll inte göras tillgängligt för andra. Cookiestöld är handlingen av otillåten avlyssning av cookies av tredje part.

Cookies kan stjälas med hjälp av trafikanalys  – detta kallas sessionskapning. Nätverkstrafik kan fångas upp av mer än bara dess avsändare och mottagare (särskilt på offentliga Wi-Fi-nätverk ). Denna trafik inkluderar även cookies som överförs över okrypterade HTTP-sessioner. Där nätverkstrafiken inte är krypterad kan angripare läsa kommunikationen från nätverksanvändare, inklusive deras cookies, med hjälp av program som kallas sniffers .

Kryptering av data i cookies av servern tar bort problemet med deras säkerhet, men det är möjligt att byta ut cookies av en angripare. För att göra det omöjligt att komma åt även krypterade cookies kan det hjälpa att upprätta en krypterad anslutning mellan användaren och servern med hjälp av HTTPS -protokollet . Servern kan också använda en speciell flagga vid inställning av cookies, varefter webbläsaren endast överför dem över en pålitlig kanal, till exempel över en SSL- anslutning [6] .

Men ett stort antal webbplatser, även med säkra HTTPS-sessioner för att autentisera användaren, skickar sedan cookies och annan data över en enklare, okrypterad HTTP-anslutning. Angripare kan enkelt fånga upp andra användares cookies och använda dem på respektive webbplats [36] .

För att säkerställa att cookien endast överförs över en HTTPS-session måste cookien ha attributet Secure.

Ett annat sätt att stjäla cookies är cross-site scripting och obehörig sändning av cookies till servrar som inte borde ta emot dem. Moderna webbläsare kan köra kodavsnitt som tas emot från servern. Om cookies är tillgängliga under denna körning kan deras innehåll hamna i en eller annan form på servrar som inte borde kunna komma åt dem. Att kryptera cookien hjälper inte i det här fallet [37] .

Följande typ av cross-site scripting används vanligtvis på webbplatser där användare tillåts skicka meddelanden med HTML-innehåll. Genom att infoga lämplig PHP/Javascript-kod i ett meddelande kan en angripare få cookies från andra användare.

Dessa attacker kan förhindras genom att sätta HttpOnly-flaggan [38] , vilket gör cookies otillgängliga för skript på klientsidan. Däremot bör webbutvecklare överväga skydd mot cross-site scripting under utvecklingen av webbplatser [39] .

Cookie spoofing

Även om cookies i teorin bör bevaras och skickas tillbaka till servern oförändrade, kan en angripare ändra deras innehåll innan de skickas. Till exempel kan cookies innehålla det totala belopp som användaren måste betala för sina köp; genom att ändra detta värde kommer angriparen att kunna betala mindre än det inställda beloppet. Processen att ändra innehållet i en cookie kallas cookie-spoofing .

För att skydda mot sådana attacker lagrar de flesta webbplatser endast sessions-ID:t i en cookie, ett slumpmässigt genererat nummer eller en uppsättning tecken som används för att identifiera sessionen, medan all annan information lagras på servern. I det här fallet är byte av kakor mycket svårare.

Cross-site cookies

Varje sida måste ha sina egna cookies, och example1.com får inte ändra eller ställa in en annan exempel2.orgs cookie. Webbläsares sårbarheter tillåter skadliga webbplatser att bryta mot denna regel. Detta liknar cookie-spoofing, men här attackerar angriparen användare med sårbara webbläsare, inte webbplatsen direkt. Sessionsidentifierare kan vara målet för sådana attacker.

För skydd rekommenderas användare att använda de senaste versionerna av webbläsare som löser det här problemet.

Instabilitet mellan klient och server

Cookies kan orsaka konflikter mellan klient och server. Om användaren tar emot cookien och sedan klickar på webbläsarens bakåtknapp, är webbläsarens tillstånd redan annorlunda än när kakan togs emot. Låt oss till exempel ta en e-butik med en cookie-baserad kundvagn: användaren lägger till ett köp i kundvagnen och klickar sedan på bakåtknappen, men köpet ligger kvar i varukorgen, även om användaren kan ha velat ångra köpet . Detta kan leda till förvirring och fel. Webbutvecklare bör ha detta i åtanke och vidta åtgärder för att hantera sådana situationer.

Cookies utgångsdatum

Beständiga cookies har kritiserats av experter för deras långa hållbarhet, vilket gör att webbplatser kan spåra och profilera användare över tid [40] . Säkerhetsfrågor är också inblandade här, eftersom stulna persistenta cookies kan användas under en betydande tidsperiod.

Dessutom kan en väldesignad skadlig programvara som kan lanseras efter användarautentisering överföra sessionscookies till angriparens dator, vilket i en första uppskattning kommer att tillåta besök på en säker webbplats utan att ange ett användarnamn och lösenord under en godtyckligt lång tid.

Vanliga cookies har en mycket lång, men begränsad "livstid", varefter de raderas. Dessutom kan eventuella cookies i webbläsaren raderas med ett speciellt alternativ. Som ett resultat av detta slutar webbläsaren att identifiera besökaren när den går in på webbplatsen igen. Den polska specialisten Sammy Kamkar bestämde sig för att systematisera de mest "överlevande" cookies, vilket resulterade i ett JavaScript-bibliotek som heter Everycookie. Dessa under-cookies tillåter teoretiskt sett alla webbplatsbesökare att identifieras när de återvänder till sidan. En webbplats som använder Everycookie-biblioteken kringgår lätt alla anonymitetsåtgärder (även om vissa antivirus kan upptäcka sådana webbplatser som farliga). För att skydda mot Everycookie rekommenderas det att använda läget Privat surfning eller speciella program som Mil Shield.

Användning av cookies

Sessionshantering

Cookies introducerades ursprungligen för att göra det möjligt för användare att registrera de varor de vill köpa när de navigerar på en webbplats (virtuell "shopping cart" eller "shopping cart") [41] [42] . Idag lagras dock vanligtvis innehållet i en användares kundvagn i en databas på servern snarare än i en cookie om kunden. För att hålla reda på vilken användare som tillhör vilken kundvagn skickar servern en cookie till klienten som innehåller ett unikt sessions-ID (vanligtvis en lång sträng av slumpmässiga bokstäver och siffror). Eftersom cookies skickas till servern på varje begäran från klienten kommer detta sessions-ID att skickas tillbaka till servern varje gång användaren besöker en ny sida på webbplatsen som låter servern veta vilken kundvagn som ska visas för användaren.

En annan populär användning av cookies är för att logga in på webbplatser. När en användare besöker en webbplatss inloggningssida skickar webbservern vanligtvis en cookie till klienten som innehåller ett unikt sessions-ID. När en användare lyckas logga in kommer servern ihåg att just det sessions-ID har autentiserats och ger användaren åtkomst till dess tjänster.

Eftersom sessionscookies bara innehåller ett unikt sessions-ID, gör detta mängden personlig information som en webbplats kan lagra om varje användare praktiskt taget obegränsad – webbplatsen är inte bunden av gränser för cookiestorlek. Sessionscookies hjälper också till att minska sidladdningstider eftersom mängden information i en sessionscookie är liten och kräver liten bandbredd.

Personalisering

Cookies kan användas för att komma ihåg information om användaren för att visa dem relevant innehåll över tid. Till exempel kan en webbserver skicka en cookie som innehåller det användarnamn som senast användes för att logga in på en webbplats så att den automatiskt kan fyllas i nästa gång användaren loggar in.

Många webbplatser använder cookies för personalisering enligt användarens preferenser. Användare väljer sina preferenser genom att ange dem i ett webbformulär och skicka formuläret till servern. Servern kodar inställningarna i en cookie och skickar tillbaka kakan till webbläsaren. Således, varje gång en användare går in på en sida på webbplatsen, kan servern anpassa sidan enligt användarens preferenser. Till exempel använde Googles sökmotor en gång cookies för att låta användare (även icke-registrerade användare) bestämma hur många sökresultat per sida de vill se.

Spårning

Cookies används för att spåra användarnas surfvanor. Detta kan också göras till viss del med hjälp av IP-adressen för den dator som begär sidan eller referensfältet i HTTP-förfrågningshuvudet, men cookies möjliggör större precision. Detta kan visas om användaren begär en sida på webbplatsen, men begäran inte innehåller en cookie, servern antar att detta är den första sidan som användaren har besökt. Så servern genererar en unik identifierare (vanligtvis en sekvens av slumpmässiga bokstäver och siffror) och skickar den som en cookie till webbläsaren tillsammans med den begärda sidan.

Från och med nu kommer cookien automatiskt att skickas av webbläsaren till servern varje gång en ny sida begärs från webbplatsen. Servern skickar inte bara sidan som vanligt, utan lagrar även webbadressen till den begärda sidan, datum/tid för begäran och cookien i en loggfil.

Genom att analysera denna loggfil kan du bestämma vilka sidor användaren besökte, i vilken ordning och hur länge.

Cookie-alternativ

Vissa av de operationer som cookies används för kan implementeras med andra mekanismer. Dessa alternativ har dock sina nackdelar, vilket gör cookies ibland mer att föredra i praktiken. De flesta av dessa alternativ låter dig spåra användaren, om än på ett mindre tillförlitligt sätt än cookies. Som ett resultat av detta förblir integriteten i fara även om cookies inaktiveras av webbläsaren eller inte ställs in av servern.

IP-adress

Denna opålitliga metod för att spåra användare är beroende av att lagra IP-adresserna för de datorer som tittar på sidorna. Denna teknik har varit tillgänglig sedan World Wide Webs gryning och kräver kunskap om klientens IP-adress för att kunna ladda en sida. Denna information kan lagras på servern oavsett om cookies används eller inte.

Den här metoden är dock mindre säker än cookies eftersom datorer och proxyservrar kan delas mellan flera användare, och en dator kan använda olika IP-adresser i olika sessioner (dynamisk IP-adress).

Spårning med IP-adress kanske inte är möjlig när du använder system för bevarande av anonymitet (till exempel Tor ). I sådana system kan en enda webbläsare ha flera IP-adresser, och flera användare kan använda samma IP-adress, vilket gör det omöjligt att spåra IP-adressen.

Vissa stora internetleverantörer, inklusive AOL , skickar all webbtrafik genom ett proxynätverk , vilket också gör denna metod omöjlig att använda.

URL (frågesträng)

En mer avancerad teknik bygger på att bädda in data i URL:en. Detta görs vanligtvis med hjälp av en frågesträng, men andra delar av URL:en kan också användas. JavaScript och PHP använder dessa mekanismer i stor utsträckning när cookies är inaktiverade.

Webbservern lägger till en frågesträng till en länk till en webbsida när den skickas till webbläsaren. När användaren klickar på länken returnerar webbläsaren en frågesträng till servern.

I detta avseende är frågesträngen och cookien väldigt lika: de är delar av serverinformation som returneras av webbläsaren. Men det finns vissa skillnader: eftersom frågesträngen är en del av URL:en kommer samma information att överföras till servern när du återanvänder denna URL. Till exempel, om en användares alternativ är kodade i en URL-frågesträng och användaren skickar den URL:en till en annan användare, kommer dessa alternativ att vara giltiga för den andra användaren.

Dessutom, även om användaren upprepade gånger kommer åt samma sida, finns det ingen garanti för att frågesträngen förblir oförändrad. Till exempel, när du navigerar från webbplatsens interna sidor och från externa sökmotorer, kommer frågesträngarna att vara olika, medan cookies förblir desamma.

En annan nackdel med frågesträngen kommer ur säkerhetssynpunkt: att lagra sessions-ID:t i frågesträngen gör det lättare att attackera. Att skicka ett ID i en cookie är säkrare.

Dolda formulärfält

Ett sätt att spåra en session med ett program på serversidan är att använda webbformulär med dolda fält. Den här metoden är väldigt lik URL-frågesträngen och har nästan samma fördelar och nackdelar, och om formulärparametrarna skickas via HTTP GET-metoden kommer fälten faktiskt att bli en del av URL:en som webbläsaren skickar till servern . Men de flesta formulär behandlas av HTTP POST , där informationen varken är en del av URL:en eller cookien.

Detta tillvägagångssätt har två fördelar när det gäller spårning: för det första, att klistra in informationen i HTML-koden och i POST, och inte i URL:en, innebär att den genomsnittliga användaren helt enkelt inte kommer att märka det, och för det andra, sessionsinformationen kopieras inte med att kopiera URL:en (t.ex. när en användare skickar en länk via e-post). Nackdelen med denna metod är att sessionsinformationen finns i HTML-koden, så webbsidan måste genereras varje gång den efterfrågas, vilket ökar belastningen på webbservern.

HTTP-autentisering

HTTP-protokollet inkluderar grundläggande autentisering och kryptering, som endast tillåter åtkomst till en sida när användaren anger rätt användarnamn och lösenord. Om servern begär detta kontaktar webbläsaren användaren och, efter att ha mottagit nödvändiga data, sparar och använder den för att komma åt andra sidor utan att användaren behöver gå in på dem igen. Ur användarens synvinkel är effekten densamma som vid användning av en cookie: ett användarnamn och lösenord krävs endast en gång, och sedan ges användaren åtkomst till webbplatsen. Med Basic Authentication skickas användarnamn/lösenordskombinationen okrypterad till servern med varje webbläsarförfrågan. Det betyder att om någon avlyssnar trafiken kommer de att kunna få denna information och sedan använda den. Med krypterad autentisering krypteras användarnamnet och lösenordet med en slumpmässig nyckel som genereras av servern.

Sparar på klientsidan

Vissa webbläsare tillåter en sida att lagra information lokalt för senare hämtning. Internet Explorer, till exempel, stöder lagring av information i historik, favoriter , XML- lagring, eller tillåter direkt lagring av en webbsida till disk [43] .

JSON Web Tokens

JSON Web Token (JWT) är ett fristående paket med information som kan användas för att lagra information om en användares identitet och identitet. Detta gör att de kan användas istället för sessionscookies. Till skillnad från cookies, som automatiskt bifogas till varje HTTP-begäran av webbläsaren, måste JWT:er uttryckligen bifogas av webbapplikationen till varje HTTP-begäran.

DOM Window.name

Alla moderna webbläsare kan lagra en ganska stor mängd data (2-32 MB) via JavaScript med hjälp av egenskapen window.name DOM. Denna data kan användas i stället för sessionscookies och är även domänöverskridande. Tekniken kan kombineras med JSON/JavaScript-objekt för att lagra komplexa uppsättningar av sessionsvariabler [44] på klientsidan.

Webbläsarens cache

Webbcachen kan också användas för att lagra information som kan användas för att spåra enskilda användare. Denna metod drar fördel av det faktum att webbläsaren kommer att använda resurserna som är lagrade i cachen istället för att ladda ner dem från webbplatsen när den fastställer att den senaste versionen av resursen redan finns i cachen.

En sida kan till exempel innehålla en länk <script type="text/javascript" src="example.js">. Skriptet ställer in en unik identifierare för användaren (till exempel var userId = 3243242;). Efter det första besöket, varje gång användaren besöker sidan, kommer denna fil att laddas från cachen istället för att laddas från servern. Därför kommer dess innehåll aldrig att förändras.

Den enda fördelen med denna metod är arbete över platsen, vilket tillåter obehörig övervakning av användaren. Nackdelar - icke-trivial överföring av denna information till servern och extrem ohanterlighet: webbläsaren kan förlora cachad data när som helst, beroende på inställningar, minnesstorlek och diskutrymme. Mozilla Firefox 85+ tillåter inte spårning över flera webbplatser via cache [45] .

Webbläsarinställningar

De flesta moderna webbläsare stöder cookies och låter användaren inaktivera dem. Följande är vanliga alternativ [46] :

Se även

Anteckningar

  1. 1 2 3 Vanliga frågor om cookies  (engelska)  (länk ej tillgänglig) . Microsoft. Hämtad 12 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  2. Problem med nätbutikens arbete (otillgänglig länk) . OZON.ru. _ Hämtad 12 augusti 2008. Arkiverad från originalet 14 september 2008. 
  3. Hjälpcenter, webbsökning (nedlänk) . Google . Hämtad 12 augusti 2008. Arkiverad från originalet 26 augusti 2011. 
  4. Kiwifågel. Riktad reklam – ett hot mot integriteten? (inte tillgänglig länk) . Computerra . Hämtad 12 augusti 2008. Arkiverad från originalet 5 april 2013. 
  5. Netscape. Utkast till Cookie Specification  (eng.) (txt)  (länk ej tillgänglig) . Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  6. 1 2 RFC 2109 och RFC 2965  - HTTP State Mechanism ( IETF )
  7. Andrey Alikberov. Vad är cookies och hur man arbetar med dem (otillgänglig länk) (1998). Hämtad 2 augusti 2008. Arkiverad från originalet 1 september 2011. 
  8. John Schwartz. Att ge webben ett minne kostar dess användare Sekretess  (engelska)  (länk ej tillgänglig) . New York Times (4 september 2001). Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  9. Netscape Communications introducerar ny nätverksfri Internetnavigator  (engelska)  (länk ej tillgänglig) . CNET Networks (13 oktober 1994). Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  10. Mark Andreassen. Frid, här är den!  (engelska) (13 oktober 1994). — Meddelande på Usenet . Hämtad 7 augusti 2008. Arkiverad från originalet 2 december 2007.
  11. Sandy Hardmyer. Historien om Internet Explorer  (engelska)  (länk ej tillgänglig) . Microsoft (25 augusti 2005). Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  12. Roger Clark. Cookies  (engelska)  (inte tillgänglig länk) (1 juni 1998). Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  13. "Underhålla sessionstillstånd med cookies" . Microsoft Developer Network (22 oktober 2012). Hämtad 31 mars 2018. Arkiverad från originalet 1 april 2018.
  14. Tredjepartsdomäner . webcookies.org. . Hämtad 17 mars 2019. Arkiverad från originalet 1 juli 2019.
  15. Antal kakor . webcookies.org . Hämtad 17 mars 2019. Arkiverad från originalet 1 juli 2019.
  16. Lär dig mer om den offentliga suffixlistan . Publicsuffix.org (2016). Hämtad 17 mars 2019. Arkiverad från originalet 14 maj 2016.
  17. Mayer, Jonathan. Spåra spårarna: Microsoft Advertising . Centrum för internet och samhälle (2011). Hämtad 22 mars 2019. Arkiverad från originalet 22 mars 2019.
  18. Vijayan, Jaikumar. Microsoft inaktiverar "supercookies" som används på MSN.com-besökare (2014). Hämtad 22 mars 2019. Arkiverad från originalet 22 mars 2019.
  19. Exempel på cookieprefix . googlechrome.github.io Hämtad 2 september 2019. Arkiverad från originalet 2 september 2019.
  20. Duct Tape och Baling Wire–Cookie-  prefix . text/vanlig (9 oktober 2015). Hämtad 2 september 2019. Arkiverad från originalet 2 september 2019.
  21. Ross Shannon. Cookies och JavaScript  (engelska)  (inte tillgänglig länk) (26 februari 2007). Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  22. Cookies och auktorisering  (eng.)  (otillgänglig länk) . MSDN . Hämtad 13 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  23. Stöd för webbläsare  (engelska)  (länk ej tillgänglig) . University at Buffalo (15 november 2004). Hämtad 13 augusti 2008. Arkiverad från originalet 14 september 2005.
  24. 1 2 David Whalen. Inofficiella FAQ om cookies  (engelska)  (inte tillgänglig länk) (6 augusti 2002). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  25. Joanna Geary. Spåra spårarna: Vad är cookies? En introduktion till webbspårning . The Guardian (23 april 2012). Hämtad 28 september 2018. Arkiverad från originalet 27 juni 2017.
  26. Brian Quinton. Användare förstår inte, kan inte radera cookies  (engelska)  (länk ej tillgänglig) (18 maj 2005). Hämtad 7 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  27. Cookie Security Report  = Bittersweet cookies . Vissa säkerhets- och integritetsfrågor // European Network Security and Information Security Agency (ENISA) . — 2011.  
  28. CIA ertappad med att stjäla kakor  (eng.)  (otillgänglig länk) . CBS News (20 mars 2002). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  29. Byrån tar bort olagliga spårningsfiler  (engelska)  (otillgänglig länk) . Associated Press (29 december 2005). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  30. Direktivet om integritet och elektronisk kommunikation  (engelska)  (länk ej tillgänglig) (12 juli 2002). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  31. Direktiv 2009/136/EG av den 25 november 2009  (engelska) . Hämtad 6 juni 2017. Arkiverad från originalet 19 juni 2017.
  32. Artikel 29-arbetsgruppen - ståndpunkt 04/2012 av den 7 juni 2012 om undantag från kravet att erhålla samtycke för cookies  (eng.) . Hämtad 6 juni 2017. Arkiverad från originalet 21 juli 2017.
  33. ↑ Förslag till e-integritetsförordning  . Hämtad 6 juni 2017. Arkiverad från originalet 29 september 2018.
  34. Elena Neb. Nya regler för att arbeta med personuppgifter om européer . texterra.ru (26 juni 2018). Hämtad 28 september 2018. Arkiverad från originalet 28 september 2018.
  35. Cookie-inställningar i Opera 9  (engelska)  (otillgänglig länk) . Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  36. Wi-fi hacking webbmail  (engelska)  (länk ej tillgänglig) . BBC News (3 augusti 2007). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  37. Hur ser XSS-cookiestöld ut?  (engelska)  (otillgänglig länk) . Cgisecurity.com (maj 2002). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  38. Minska risken för cross-site scripting med HTTP-endast cookies  (eng.)  (död länk) . Microsoft. Hämtad 8 augusti 2008. Arkiverad från originalet 13 augusti 2011.
  39. Michael Howard; Keith Brown. 10 tips för att skydda din kod  (engelska)  (länk ej tillgänglig) . Microsoft (2000). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  40. Eleanor Mills. Google minskar utgången av cookies för att förbättra säkerheten  (engelska)  (död länk) . CNET Networks (16 juli 2007). Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  41. Kesan, Jey; och Shah, Rajiv. dekonstruerar kod.
  42. David Kristol. HTTP-kakor: Standarder, integritet och politik . — ACM Transactions on Internet Technology. - 2001. - S. 151-198.
  43. Introduktion till lagring  (engelska)  (länk ej tillgänglig) . MSDN . Hämtad 8 augusti 2008. Arkiverad från originalet 26 augusti 2011.
  44. ThomasFrank.se . ThomasFrank.se (22 maj 2010). Hämtad 22 mars 2019. Arkiverad från originalet 23 mars 2019.
  45. Firefox 85 slår ner på supercookies - Mozilla Security Blog . Hämtad 9 mars 2021. Arkiverad från originalet 3 februari 2021.
  46. David Whalen. Inofficiella Cookie FAQ v2.6 (2002). Hämtad 24 juli 2008. Arkiverad från originalet 26 augusti 2011.
  47. Tredjepartscookies, DOM-lagring och sekretess: Matt Mastraccis blogg . grack.com (2010). Hämtad 22 mars 2019. Arkiverad från originalet 19 augusti 2018.
  48. Fler företag motsätter sig Googles FLoC-teknik för att ersätta cookies Arkiverad 28 april 2021 på Wayback Machine Webbläsartillverkare övergav Googles inriktningsteknik för cookiesersättning Arkiverad 28 april 2021 på Wayback Machine [1] Arkiverad 28 april 2021 på Wayback Machine

Länkar