Cookie -k ( angolul cookie , lit. - "cookie") - egy webszerver által küldött és a felhasználó számítógépén tárolt kis adat . A webkliens (általában egy webböngésző ) elküldi ezt az adatrészt a webszervernek egy HTTP -kérés részeként, amikor megpróbál megnyitni egy oldalt a megfelelő webhelyen . Adatmentésre szolgál felhasználói oldalon, a gyakorlatban általában [1] :
A cookie-k böngészőjének támogatása (a tárolt cookie-k elfogadása, mentése és későbbi továbbítása a szerverre) számos hozzáférési korlátozással rendelkező webhelynek, a legtöbb online áruháznak szüksége van [2] . Sok webhely kialakításának és viselkedésének személyre szabása is a cookie-kon alapul [1] .
A cookie-kat könnyű elfogni és hamisítani (például hozzáférést lehet szerezni egy fiókhoz), ha a felhasználó titkosítatlan kapcsolatot használ a szerverrel. Veszélyben vannak azok a felhasználók, akik nyilvános Wi-Fi hozzáférési pontokon keresztül érik el az internetet, és nem használnak olyan mechanizmusokat, mint az SSL és a TLS . A titkosítás más, a továbbított adatok biztonságával kapcsolatos problémákat is megold.
A legtöbb modern böngésző lehetővé teszi a felhasználók számára, hogy eldöntsék, hogy elfogadják-e a cookie-kat, de letiltása egyes webhelyeket használhatatlanná tesz. Ezen túlmenően egyes országok törvényei szerint (például az Európai Unió 2016-os rendelete szerint, lásd az általános adatvédelmi rendeletet ) az oldalaknak a cookie beállítása előtt kötelesek kérni a felhasználói hozzájárulást.
A cookie-kat a webszerverek a felhasználók azonosítására és a róluk szóló adatok tárolására használják.
Például, ha az oldal cookie-k segítségével van bejelentkezve, akkor miután a felhasználó megadja adatait a bejelentkezési oldalon, a cookie-k lehetővé teszik a szerver számára, hogy emlékezzen arra, hogy a felhasználót már azonosították, és hozzáférhet a vonatkozó szolgáltatásokhoz és műveletekhez [1 ] .
Sok webhely cookie-kat is használ a felhasználói preferenciák mentésére. Ezek a beállítások használhatók a személyre szabáshoz, amely magában foglalja a megjelenés és a funkcionalitás kiválasztását. Például a Wikipédia lehetővé teszi a jogosult felhasználók számára, hogy megválasszák a webhely kialakítását. A Google keresőmotorja lehetővé teszi a felhasználóknak (beleértve azokat is, akik nem regisztráltak rá), hogy megválasszák az egy oldalon megjelenő keresési eredmények számát [3] .
A sütiket arra is használják, hogy nyomon kövessék a felhasználói tevékenységet az oldalon. Ez általában statisztikagyűjtés céljából történik, és a hirdető cégek az ilyen statisztikák alapján anonim felhasználói profilokat alkotnak a hirdetések pontosabb célzása érdekében [4] .
Technikailag a cookie-k olyan adatok, amelyeket kezdetben egy webszerver küld el a böngészőnek. A webhely minden további látogatása során a böngésző visszaküldi azokat a szervernek. Cookie nélkül az egyes weboldal-megtekintések elszigetelt műveletek, amelyek nem kapcsolódnak ugyanazon az oldalon lévő más oldalak böngészéséhez, ugyanazzal a cookie-val azonosíthatja a különböző oldalak megtekintése közötti kapcsolatot. Amellett, hogy a webszerver küldi őket, a cookie-k szkriptnyelvekkel , például JavaScripttel is létrehozhatók, ha a böngésző támogatja és engedélyezve van.
A specifikációk [5] [6] meghatározzák azt a minimális mennyiséget, amelyet a böngészőknek biztosítaniuk kell a cookie-k tárolására. Így a böngészőnek legalább 300, egyenként 4096 bájtos cookie-t kell tárolnia, és szerverenként vagy tartományonként legalább 20 cookie-t .
A népszerű böngészőkben minden domainhez megfelelő maximálisan tárolt cookie-k vannak:
A gyakorlatban egyes böngészők szigorúbb korlátozásokat írhatnak elő. Például az Internet Explorer 4096 bájtot biztosít az összes cookie számára ugyanabban a tartományban.
Az RFC 2965 3.1 szakasza értelmében a cookie-nevek nem különböztetik meg a kis- és nagybetűket .
A sütik beállíthatják törlésük dátumát, ebben az esetben a böngésző automatikusan törli azokat a megadott időn belül. Ha nincs megadva törlési dátum, a cookie-k törlődnek, amint a felhasználó bezárja a böngészőt. Így a lejárati dátum megadása lehetővé teszi a cookie-k egynél több munkameneten keresztüli tárolását, és az ilyen cookie-kat állandónak nevezzük. Például egy online áruház perzisztens cookie-k segítségével tárolhatja a felhasználó által a kosárba helyezett termékek kódjait – és még ha a felhasználó bezárja is a böngészőt vásárlás nélkül, a következő bejelentkezéskor nem lesz hogy újjáépítsék a szekeret.
A cookie-k tárolása a webszervertől, a domaintől vagy az aldomaintől függően is korlátozott lehet.
Az egyik változat szerint a "cookie-k" (cookie-k) kifejezés a " mágikus cookie -kból " [7] származik – olyan adatok halmazából, amelyeket a program fogad, majd változatlanul küld vissza. 1994 júniusában Lou Montullinak az az ötlete támadt, hogy webkapcsolatban használja őket [8] . Abban az időben a Netscape Communications alkalmazottja volt , amely egy megrendelt e-kereskedelmi csomagot fejleszt. A cookie-k megoldást jelentenek a virtuális bevásárlókosár megbízható megvalósításának problémájára.
John Giannandrea segítségével Montulli ugyanabban az évben megírta a süti kezdeti specifikációját. A Mosaic Netscape 0.9beta, 1994. október 13-án megjelent [9] [10] , már támogatta a cookie-kat. A sütiket először a Netscape webhely laborján kívül használták, és meghatározták, hogy a felhasználó korábban járt-e az oldalon. Montulli 1995-ben nyújtott be szabadalmat , és 1998-ban megkapta. Az Internet Explorer az 1995 októberében kiadott 2-es verziójával kezdte meg a cookie-k támogatását [11] .
Bár egyesek már 1995 első negyedévében tudtak a cookie-k létezéséről [12] , a nagyközönség csak a Financial Times 1996. február 12-i cikke után szerzett tudomást róluk . Ugyanebben az évben a cookie-k a média figyelmének középpontjába kerültek, különösen a magánélet veszélyeztetése miatt . Az Egyesült Államok Szövetségi Kereskedelmi Bizottsága két meghallgatáson is megvizsgálta a sütiket 1996-ban és 1997-ben.
A süti specifikációk fejlesztése nem állt meg itt. A hivatalos specifikáció első megbeszélései 1995 áprilisában kezdődtek. Az IETF - en belül egy ad hoc munkacsoport alakult . A Netscape specifikációt választották kiindulópontnak. 1996 februárjában egy munkacsoport a harmadik féltől származó cookie-kat súlyos adatvédelmi fenyegetésként azonosította. Az így kapott specifikációt 1997 februárjában adták ki RFC 2109 néven . Kijelentette, hogy a harmadik féltől származó cookie-kat vagy le kell tiltani, vagy legalábbis alapértelmezés szerint nem működnek.
Abban az időben a reklámcégek már harmadik féltől származó cookie-kat használtak, és az RFC 2109 ajánlásokat sem a Netscape böngészők, sem az Internet Explorer nem támogatták. Később, 2000 októberében az RFC 2109 -et az új RFC 2965 specifikáció váltotta fel .
A munkamenet-cookie -k , más néven ideiglenes cookie -k , csak az ideiglenes memóriában léteznek, amíg a felhasználó egy webhely oldalán tartózkodik. A böngészők általában törlik a munkamenet sütiket, miután a felhasználó bezárja a böngészőablakot [13] . Más típusú sütikkel ellentétben a munkamenet-cookie-knak nincs lejárati dátumuk, ezért a böngészők munkamenet-cookie-ként értelmezik őket.
Ahelyett, hogy a böngésző bezárásakor törlődnek, mint a munkamenet-sütik, az állandó cookie -k egy adott napon vagy egy bizonyos idő elteltével törlődnek. Ez azt jelenti, hogy minden alkalommal, amikor a felhasználó meglátogatja azt a webhelyet, amelyhez a cookie tartozik, a cookie-val kapcsolatos információk elküldésre kerülnek a szervernek. Emiatt a perzisztens cookie-kat néha nyomkövető cookie -knak is nevezik, mivel a hirdetők hosszabb ideig használhatják őket a felhasználói preferenciák rögzítésére. Használhatók azonban „békés” célokra is, például annak elkerülésére, hogy minden alkalommal, amikor felkeresi az oldalt, ne kelljen újra megadni az adatokat.
A cookie domain attribútuma általában megegyezik a webböngésző címsorában megjelenő domainnel. Ezt hívják első sütinek. A harmadik féltől származó cookie azonban más domainhez tartozik, mint a címsorban. Ez a fajta cookie általában akkor jelenik meg, ha a weboldalak külső webhelyekről származó tartalmat, például szalaghirdetéseket tartalmaznak. Ez lehetőséget nyit a felhasználó böngészési előzményeinek nyomon követésére, és a hirdetők gyakran használják arra, hogy releváns hirdetéseket jelenítsenek meg minden felhasználó számára.
Példaként tegyük fel, hogy egy felhasználó felkeresi a www.example.org webhelyet. Ez a webhely az ad.foxytracking.com webhelyről származó hirdetéseket tartalmaz, amelyek betöltésekor a hirdetési domainhez (ad.foxytracking.com) tartozó cookie-t állítanak be. A felhasználó ezután felkeres egy másik www.foo.com webhelyet, amely szintén az ad.foxytracking.com webhelyről származó hirdetéseket tartalmaz, és beállítja az ehhez a domainhez tartozó cookie-t (ad.foxytracking.com). Végül is mindkét cookie elküldésre kerül a hirdetőnek, amikor hirdetése betöltődik, vagy felkeresik a webhelyét. A hirdető ezután ezeket a cookie-kat használhatja a felhasználó böngészési előzményeinek összegyűjtésére az összes olyan webhelyen, amelyen a hirdető hirdetése található.
2014-től egyes webhelyek olvasási cookie-kat helyeztek el több mint 100 harmadik fél domainjén [14] . Weboldalonként átlagosan 10 cookie lett beállítva, a cookie-k maximális száma (mind harmadik felek, mind harmadik felek esetében) meghaladja a 800-at [15] . A legtöbb modern webböngésző olyan adatvédelmi beállításokat tartalmaz, amelyek blokkolhatják a harmadik féltől származó cookie-kat.
A szuper cookie legfelső szintű domain eredetű (pl . .ru ) vagy nyilvános utótagú (pl. .co.uk) cookie. A szokásos cookie-k viszont egy adott domain névből származnak, például az example.com.
A szupersütik potenciális biztonsági problémát jelenthetnek, ezért gyakran blokkolják őket a webböngészők. Ha egy böngésző felold egy rosszindulatú webhely blokkolását, a támadó szuper cookie-t állíthat be, és potenciálisan megzavarhatja vagy kiadhatja a jogos felhasználói kéréseket egy másik webhelynek, amely ugyanazt a legfelső szintű domaint vagy nyilvános utótagot használja, mint a rosszindulatú webhely. Például egy .com eredetű szupercookie rosszindulatúan befolyásolhatja az example.com-nak küldött kérést, még akkor is, ha a cookie nem az example.com webhelyről jött létre. Ez felhasználható hamis bejelentkezésekre vagy felhasználói adatok megváltoztatására.
Az utótagok nyilvános listája [16] segít csökkenteni a szupersütik kockázatát. A nyilvános utótagok listája egy több gyártótól származó kezdeményezés, amelynek célja, hogy pontos és naprakész listát biztosítson a domainnév-utótagokról. Előfordulhat, hogy a böngészők régebbi verziói nem rendelkeznek naprakész listával, ezért ki vannak téve bizonyos domainekről származó szuper cookie-knak.
A "szupercookie" (szuper-süti) kifejezést néha olyan technológiák nyomon követésére használják, amelyek nem használnak HTTP cookie-kat. 2011 augusztusában két ilyen „szupercookie”-mechanizmust fedeztek fel a Microsoft webhelyein: a cookie-szinkronizálást, amely egy MUID (egyedi gépazonosító) cookie-t hoz létre, és egy ETag cookie-t [17] . A média érdeklődése miatt a Microsoft később letiltotta ezt a kódot [18] .
Mivel a cookie-k nagyon könnyen eltávolíthatók a böngészőből, a programozók keresik a módokat a felhasználók azonosítására még a böngésző előzményeinek teljes törlése után is. Az egyik ilyen megoldás a zombi cookie-k (vagy evercookie , vagy persistent cookie -k ) – nem törölhető vagy nehezen törölhető cookie-k, amelyek JavaScript segítségével visszaállíthatók a böngészőben. Ez azért lehetséges, mert a webhely egyidejűleg használja az összes elérhető böngészőtárolót a cookie-k tárolására ( HTTP ETag, Session Storage, Local Storage, Indexed DB ), beleértve az olyan alkalmazástárolókat, mint a Flash Player ( Helyi megosztott objektumok ), a Microsoft Silverlight ( Isolated Storage ) és a Java. ( Java Persistence API ). Amikor a program azt észleli, hogy a böngészőben nem található süti, amelyről más üzletekben információ található, azonnal visszaállítja azt a helyére, és ezáltal azonosítja az oldal felhasználóját.
Az RFC 6265 konkrét utasításokat ad az egyes cookie-paraméterek értelmezéséhez:
2015-ben jóváhagytak egy dokumentumot , amely frissítette az RFC 6265 specifikációt , amely elnevezési korlátozásokat adott a cookie-kra vonatkozóan. A további biztonság érdekében a szakértők speciális névelőtagokat javasoltak __Secure-és __Host-, jelezve a böngészőnek, hogy különleges követelményeknek kell megfelelnie, amikor cookie-kat fogad a szervertől [19] .
Ha a felsorolt követelmények közül legalább egy megsérül, a cookie-k böngészőbe történő telepítése elutasításra kerül. Az előtagok támogatása a Chrome 49+, a Firefox 50+ és az Opera 36+ verziókban valósul meg [20] .
Ha a fenti opciók mindegyike engedélyezve van, a szervertől érkező cookie beállítására vonatkozó kérés így fog kinézni:
Set-Cookie: __Secure-name=value; max-age=31536000; domain=example.com; path=/; secure; httponly; samesite=lax
Minden más HTTP-fejléchez hasonlóan a cookie-t is el kell küldeni a böngészőnek , mielőtt bármilyen adatot küldene, beleértve az üres karakterláncokat és a szóköz karaktereket (ez a HTTP protokoll korlátozása).
Oldal lekérésekor a böngésző egy rövid szöveget küld HTTP kéréssel a webszervernek. Például a http://www.example.org/index.html oldal eléréséhez a böngésző a következő kérést küldi a www.example.org szervernek:1
|
GET /index.html HTTP/1.1 |
||
| böngésző | → | szerver |
A szerver úgy válaszol, hogy elküldi a kért oldalt egy HTTP-választ tartalmazó szöveggel együtt. Tartalmazhat egy utasítást a böngészőnek a cookie mentésére:
|
HTTP/1.1 200 OK |
||
| böngésző | ← | szerver |
A karakterlánc Set-cookiecsak akkor kerül elküldésre, ha a szerver azt akarja, hogy a böngésző mentse a cookie-t. Ebben az esetben, ha a böngésző támogatja a cookie-kat, és azok elfogadása engedélyezett, a böngésző megjegyzi a karakterláncot name=value(név = érték), és minden további kéréssel visszaküldi a szervernek. Például a következő http://www.example.org/spec.html oldal lekérésekor a böngésző a következő kérést küldi el a www.examle.org szervernek:
|
GET /spec.html HTTP/1.1 |
||
| böngésző | → | szerver |
Ez a kérés abban különbözik az első kéréstől, hogy tartalmazza azt a karakterláncot, amelyet a szerver korábban küldött a böngészőnek. Így a szerver tudni fogja, hogy ez a kérés kapcsolódik az előzőhöz. A szerver a kért oldal elküldésével és esetleg új cookie-k hozzáadásával válaszol.
A cookie értékét a szerver újsorok küldésével módosíthatja Set-Cookie: name=new_value. A böngésző ezután lecseréli az azonos nevű régi cookie-t az új karakterláncra.
A cookie-kat olyan nyelvű programok is beállíthatják, mint például a JavaScript, oldalak szövegébe ágyazva, vagy a böngészőben futó hasonló szkriptek. A JavaScript a dokumentumobjektum cookie tulajdonságát használja ehhez document.cookie. Például document.cookie="temperature=20"létrehoz egy "hőmérséklet" nevű cookie-t, amelynek értéke 20 [21] .
A kiszolgáló cookie-kat használhat a korábban hitelesített felhasználók azonosítására. Ez így történik [22] :
Ezt a módszert széles körben használják számos webhelyen, például a Yahoo! , a Wikipédián és a Facebookon .
Sok böngésző (különösen az Opera, FireFox) a cookie-k tulajdonságainak szerkesztésével szabályozhatja a webhelyek viselkedését. A nem perzisztens (munkamenet) cookie-k lejárati dátumának megváltoztatásával például formálisan korlátlan munkamenetet kaphat egy webhelyen történő engedélyezés után. A cookie-k szabványos eszközökkel történő szerkesztése nem érhető el az Internet Explorerben. Más mechanizmusok, például a JavaScript használatával azonban a felhasználó módosíthatja a cookie-t. Ezenkívül lehetőség van a munkamenet-cookie-k állandóra (lejárati dátummal) való helyettesítésére.
A szerverszoftver azonban képes nyomon követni az ilyen próbálkozásokat. Ennek érdekében a szerver egy bizonyos időtartamra cookie-t bocsát ki, és minden alkalommal, amikor a felhasználó hozzáfér a szerverhez, ráírja magára, vagy titkosított formában magukba a cookie-kba a cookie-k lejárati dátumát. Ha a böngésző által küldött süti lejárati dátuma eltér a szerveren tárolttól vagy a cookie-ban foglaltaktól, akkor a cookie lejárati dátumát próbálják meghamisítani. A szerver válaszolhat, például megkérheti a felhasználót az újbóli engedélyezésre.
A legtöbb modern böngésző támogatja a cookie -kat [23] , és általában a felhasználó választhat, hogy használja-e a cookie-kat vagy sem. A leggyakoribb böngészőbeállítások: [24] :
A legtöbb JavaScript-kompatibilis böngésző lehetővé teszi a felhasználó számára, hogy az adott webhelyen aktív cookie-kat lásson beírásával javascript:alert(document.cookie)vagy javascript:prompt(document.cookie)a böngésző címsorába [24] . Egyes böngészők tartalmaznak egy cookie-kezelőt, amely lehetővé teszi a felhasználó számára a böngészőben tárolt cookie-k szelektív megtekintését és törlését.
Van egy tévhit, hogy a cookie-k programok, és önállóan is nyomon tudják követni a felhasználói műveleteket, bár ezek csak a böngésző által a számítógépen tárolt adatok [25] . Az amerikai Insight Express cég 2005-ben végzett felmérése szerint a válaszadók 25%-a biztos ebben [26] .
A sütik jelentős hatást gyakorolnak az internetezők anonimitására és a felhasználói adatok védelmére . Bár a cookie-kat csak a rendeltetésük szerinti tartomány kiszolgálóinak küldik, a weboldalak képeket vagy egyéb összetevőket tölthetnek be más tartományokból. Az ezen összetevők más tartományokból történő betöltése során kapott cookie-kat "harmadik félnek" nevezik [27] .
A reklámcégek harmadik féltől származó cookie-kat használnak a felhasználó mozgásának nyomon követésére az oldalakon. Egy hirdetőcég különösen nyomon tudja követni a felhasználókat az összes olyan webhelyen, ahol hirdetési szalaghirdetéseik fel vannak szerelve . A felhasználó által meglátogatott oldalak ismerete lehetővé teszi a hirdetés irányának megváltoztatását a felhasználó preferenciáitól függően.
A felhasználói profilalkotást potenciális adatvédelmi kockázatnak tekintik még akkor is, ha egyetlen domainen keresztül követik nyomon, de különösen akkor, ha több domainen keresztül követik nyomon harmadik féltől származó cookie-k segítségével. Emiatt egyes országokban törvény szabályozza a sütiket.
Az Egyesült Államok kormánya 2000-ben szigorú cookie-törvényeket vezetett be, miután kiderült, hogy az Egyesült Államok Kábítószer-ellenőrzési Ügynöksége cookie-kat használt a felhasználók nyomon követésére, akik megtekintették a kábítószer-ellenes hirdetéseiket az interneten. 2002-ben Daniel Brandt felfedezte, hogy a CIA állandó cookie-kat helyez el a számítógépeken, amelyek megőrzési időszaka 2010-ig terjedhet. Amikor a CIA tudomást szerzett a cookie-k illegális használatáról, az ügynökség azt mondta, hogy ez nem szándékos, és leállította a telepítésüket [28] . 2005. december 25- én Brandt felfedezte, hogy a Nemzetbiztonsági Ügynökség egy szoftverfrissítés után néhány állandó cookie-t hagyott hátra. Ezt az üzenetet követően az Ügynökség azonnal letiltotta a cookie-kat [29] .
Az Európai Unió 2002/58/EK irányelve a magánélet védelméről és az elektronikus kommunikációról [30] tartalmaz szabályokat a cookie-k használatára vonatkozóan. Az 5. cikk (3) bekezdése kimondja, hogy az adatok (beleértve a cookie-kat is) tárolására csak akkor kerülhet sor, ha:
2009-ben a 2009/136/EK irányelv [31] módosította a 2002/58/EK irányelvet, amely 2011 májusában lépett hatályba. A változások szigorították az oldal látogatóiról szóló információgyűjtés követelményeit. Az új szabályok szerint az oldaltulajdonosoknak előzetesen be kell szerezniük a látogatók hozzájárulását az információgyűjtéshez (ideértve a sütiket is), és be kell számolniuk az oldalon működő információgyűjtő eszközökről [32] .
2018 májusában lépett hatályba az Európai Unióban az Általános Adatvédelmi Rendelet , amely felváltotta a jelenlegi 2002/58/EK irányelvet, amely az Európai Unión belülről meglátogatott összes webhelyre vonatkozik, és a legtöbb cookie-t más személyes adatokkal egyenlővé teszi. Az eredeti tervezet azt javasolta, hogy a böngésző beállításai elegendő bizonyítéknak tekinthetők a felhasználó cookie beállításához való hozzájárulására vonatkozóan [33] , a végleges változat szerint pedig elegendő a cookie beállításának bejelentése [34] .
A P3P specifikáció tartalmazza azt a lehetőséget, hogy a webszerver jelentse az adatvédelem megsértését a böngészőnek, jelezve az összegyűjtött információ természetét és a gyűjtés célját. Ez magában foglalja a cookie-kon keresztül szerzett információk felhasználását. A P3P specifikáció szerint a böngésző elfogadhatja vagy elutasíthatja a cookie-kat a felhasználói preferenciáknak megfelelően, vagy kérheti a felhasználót.
Számos böngésző, köztük az Apple Safari és a Microsoft Internet Explorer 6-os és 7-es verziója támogatja a P3P specifikációkat, amelyek lehetővé teszik annak meghatározását, hogy engedélyezni kell-e a harmadik féltől származó cookie-kat. Az Opera böngésző lehetővé teszi a felhasználók számára, hogy letiltsák a harmadik féltől származó sütiket, és globális vagy egyéni biztonsági profilokat hozzanak létre a webdomainekhez [35] . A Firefox 2 eltávolította ezt a lehetőséget, de a 3-as verzióban visszaállították.
Az adatvédelmi problémákon túl a sütiknek van néhány technikai hátránnyal is, amelyek minden adatban rejlenek. Különösen nem mindig azonosítják pontosan a felhasználót, és rosszindulatú támadások okai lehetnek.
Ha egy számítógépen egynél több böngészőt használnak, általában mindegyiknek külön cookie-tárolója van. Ezért a cookie-k nem azonosítanak egy személyt, hanem fiók , számítógép és böngésző kombinációját. Így minden olyan személy, aki több fiókot, számítógépet vagy böngészőt használ, több cookie-készlettel rendelkezik.
A normál működés során a cookie-k folyamatosan cserélődnek a szerver és a felhasználó böngészője között. Mivel a sütik érzékeny információkat (felhasználónév, hozzáférési feltételek stb.) tartalmazhatnak, tartalmukat nem szabad mások számára hozzáférhetővé tenni. A cookie-lopás a cookie-k harmadik felek általi illetéktelen lehallgatásának cselekménye.
A cookie-kat forgalomelemzéssel el lehet lopni – ezt nevezik munkamenet-eltérítésnek. A hálózati forgalmat nem csak a küldő és a vevő képes elfogni (különösen a nyilvános Wi-Fi hálózatokon ). Ez a forgalom magában foglalja a titkosítatlan HTTP-munkameneteken keresztül továbbított cookie-kat is. Ahol a hálózati forgalom nincs titkosítva, a támadók a szippantóknak nevezett programok segítségével olvashatják a hálózati felhasználók kommunikációját, beleértve a cookie-jaikat is .
A cookie-kban lévő adatok szerver általi titkosítása megszünteti a biztonság kérdését, azonban lehetséges a cookie-k támadó általi helyettesítése. A titkosított cookie-khoz való hozzáférés lehetetlenné tételében segíthet, ha titkosított kapcsolatot létesít a felhasználó és a szerver között a HTTPS protokoll használatával . A szerver speciális jelzőt is használhat a cookie-k beállításakor, ami után a böngésző csak megbízható csatornán továbbítja azokat, például SSL kapcsolaton keresztül [6] .
Azonban számos webhely, még akkor is, ha biztonságos HTTPS-munkameneteket használ a felhasználó hitelesítésére, sütiket és egyéb adatokat küld egy egyszerűbb, titkosítatlan HTTP-kapcsolaton keresztül. A támadók könnyen elkaphatják más felhasználók cookie-jait, és felhasználhatják azokat a megfelelő webhelyeken [36] .
Annak biztosítása érdekében, hogy a cookie csak HTTPS-munkameneten keresztül kerüljön továbbításra, a cookie-nak rendelkeznie kell a Secure attribútummal.
A cookie-k ellopásának másik módja a webhelyek közötti szkriptelés , valamint a cookie-k jogosulatlan küldése olyan szervereknek, amelyeknek nem kellene azokat fogadniuk. A modern böngészők képesek végrehajtani a szervertől kapott kódrészleteket. Ha a végrehajtás során cookie-k állnak rendelkezésre, akkor azok tartalmuk ilyen vagy olyan formában olyan szerverekre kerülhet, amelyek nem férhetnek hozzá. A cookie titkosítása ebben az esetben nem segít [37] .
A webhelyek közötti parancsfájl következő típusát általában olyan webhelyeken használják, ahol a felhasználók HTML-tartalmú üzeneteket küldhetnek. A megfelelő PHP/Javascript kód beszúrásával az üzenetbe a támadó cookie-kat szerezhet be más felhasználóktól.
Ezek a támadások megelőzhetők a HttpOnly jelző [38] beállításával , amely a cookie-kat elérhetetlenné teszi az ügyféloldali szkriptek számára. A webfejlesztőknek azonban fontolóra kell venniük a webhelyek közötti szkriptek elleni védelmet a webhelyek fejlesztése során [39] .
Míg elméletileg a cookie-kat meg kell őrizni és változatlanul vissza kell küldeni a szervernek, a támadó megváltoztathatja azok tartalmát, mielőtt elküldené őket. Például a cookie-k tartalmazhatják azt a teljes összeget, amelyet a felhasználónak fizetnie kell vásárlásaiért; ennek az értéknek a megváltoztatásával a támadó a beállított összegnél kevesebbet tud fizetni. A cookie-k tartalmának megváltoztatásának folyamatát cookie-hamisításnak nevezik .
Az ilyen támadások elleni védelem érdekében a legtöbb webhely csak a munkamenet-azonosítót tárolja egy cookie-ban, egy véletlenszerűen generált számot vagy a munkamenet azonosítására használt karakterkészletet, míg az összes többi információt a szerver tárolja. Ebben az esetben a cookie-k helyettesítése sokkal nehezebb.
Minden webhelynek saját cookie-kkal kell rendelkeznie, és az example1.com nem módosíthatja vagy állíthatja be másik example2.org cookie-ját. A webböngésző biztonsági rései lehetővé teszik, hogy a rosszindulatú webhelyek megsértsék ezt a szabályt. Ez hasonló a cookie-hamisításhoz, de itt a támadó a felhasználókat támadja meg sebezhető böngészőkkel, nem közvetlenül a webhelyet. A munkamenet-azonosítók az ilyen támadások célpontjai lehetnek.
A védelem érdekében a felhasználóknak azt tanácsoljuk, hogy a böngészők legújabb verzióit használják, amelyek megoldják ezt a problémát.
A sütik konfliktusokat okozhatnak a kliens és a szerver között. Ha a felhasználó megkapja a cookie-t, majd rákattint a böngésző vissza gombjára, akkor a böngésző állapota már eltér attól, amikor a cookie-t megkapta. Vegyünk például egy e-shopot süti alapú bevásárlókosárral: a felhasználó a vásárlást a kosárba helyezi, majd rákattint a vissza gombra, de a vásárlás a kosárban marad, bár lehet, hogy a felhasználó el akarta mondani a vásárlást. . Ez zavarokhoz és hibákhoz vezethet. A webfejlesztőknek ezt szem előtt kell tartaniuk, és lépéseket kell tenniük az ilyen helyzetek kezelésére.
A tartós cookie-kat szakértők kritizálták hosszú eltarthatóságuk miatt, amely lehetővé teszi a webhelyek számára, hogy nyomon kövessék és profilozzák a felhasználókat az idő múlásával [40] . Itt biztonsági kérdések is felmerülnek, mivel az ellopott állandó cookie-k jelentős ideig használhatók.
Ezen túlmenően egy jól megtervezett, felhasználó hitelesítés után elindítható kártevő munkamenet-cookie-kat is képes átvinni a támadó számítógépére, ami első közelítésben lehetővé teszi egy biztonságos oldal felkeresését felhasználónév és jelszó megadása nélkül, tetszőlegesen hosszú ideig.
A hétköznapi sütik nagyon hosszú, de korlátozott "élettartamúak", ezután törlődnek. Ezenkívül a böngészőben található cookie-k egy speciális opció segítségével törölhetők. Ennek eredményeként a böngésző nem azonosítja a látogatót, amikor újra belép az oldalra. A lengyel szakember, Sammy Kamkar úgy döntött, hogy rendszerezi a leginkább "túlélhető" sütiket, aminek eredményeként egy JavaScript-könyvtár, az Everycookie néven jött létre. Ezek a csodasütik elméletileg lehetővé teszik a webhely bármely látogatójának azonosítását, amikor visszatér az oldalra. Az Everycookie könyvtárakat használó webhely könnyen megkerül minden anonimitási intézkedést (bár egyes víruskeresők veszélyesnek találhatják az ilyen webhelyeket). Az Everycookie elleni védelem érdekében javasolt a Privát böngészés mód vagy speciális programok, például a Mil Shield használata.
A sütiket eredetileg azért vezették be, hogy lehetővé tegyék a felhasználók számára, hogy rögzítsék a megvásárolni kívánt termékeket, miközben egy weboldalon navigálnak (virtuális „bevásárlókosár” vagy „bevásárlókosár”) [41] [42] . Manapság azonban a felhasználó bevásárlókosarának tartalma jellemzően a szerveren lévő adatbázisban tárolódik, nem pedig a vásárlóról szóló cookie-ban. Annak nyomon követésére, hogy melyik felhasználó melyik bevásárlókosárba tartozik, a szerver egyedi munkamenet-azonosítót (általában véletlenszerű betűkből és számokból álló hosszú láncot) tartalmazó cookie-t küld az ügyfélnek. Mivel az ügyfél minden kérésére sütiket küldenek a szervernek, ez a munkamenet-azonosító minden alkalommal visszakerül a szervernek, amikor a felhasználó a webhely új oldalára látogat, amely tájékoztatja a szervert, hogy melyik bevásárlókosarat jelenítse meg a felhasználónak.
A cookie-k másik népszerű használata a webhelyekre való bejelentkezés. Amikor a felhasználó felkeresi egy webhely bejelentkezési oldalát, a webszerver jellemzően egyedi munkamenet-azonosítót tartalmazó cookie-t küld az ügyfélnek. Amikor a felhasználó sikeresen bejelentkezik, a szerver emlékszik arra, hogy az adott munkamenet-azonosító hitelesítésre került, és hozzáférést biztosít a felhasználónak a szolgáltatásaihoz.
Mivel a munkamenet-cookie-k csak egyedi munkamenet-azonosítót tartalmaznak, ez gyakorlatilag korlátlanná teszi a webhely által az egyes felhasználókról tárolható személyes adatok mennyiségét – a webhelyet nem korlátozzák a cookie-méretre vonatkozó korlátozások. A munkamenet-cookie-k az oldalbetöltési idők csökkentésében is segítenek, mivel a munkamenet-cookie-ban lévő információ mennyisége kicsi, és kis sávszélességet igényel.
A cookie-k segítségével megjegyezhetők a felhasználóval kapcsolatos információk, hogy idővel releváns tartalmat jelenítsenek meg. Például egy webszerver küldhet egy cookie-t, amely azt a felhasználónevet tartalmazza, amellyel utoljára bejelentkezett egy webhelyre, hogy az automatikusan feltöltődjön a következő bejelentkezéskor.
Sok webhely cookie-kat használ a személyre szabáshoz a felhasználó preferenciáinak megfelelően. A felhasználók úgy választják ki preferenciáikat, hogy beírják őket egy webes űrlapba, és elküldik az űrlapot a szervernek. A szerver cookie-ba kódolja a beállításokat, és visszaküldi a cookie-t a böngészőnek. Így minden alkalommal, amikor a felhasználó hozzáfér a webhely egy oldalához, a szerver személyre szabhatja az oldalt a felhasználó preferenciái szerint. Például a Google keresőmotorja egykor cookie-kat használt annak érdekében, hogy a felhasználók (még a nem regisztrált felhasználók is) eldönthessék, hány keresési eredményt szeretnének látni oldalanként.
A cookie-k a felhasználói böngészési szokások nyomon követésére szolgálnak. Ez bizonyos mértékig megtehető az oldalt kérő számítógép IP-címének vagy a HTTP-kérés fejlécének hivatkozási mezőjének használatával is, de a cookie-k nagyobb pontosságot tesznek lehetővé. Ez akkor bizonyítható, ha a felhasználó kér egy oldalt az oldalon, de a kérés nem tartalmaz cookie-t, a szerver feltételezi, hogy ez az első oldal, amelyet a felhasználó felkeresett. Így a szerver létrehoz egy egyedi azonosítót (általában véletlenszerű betűk és számok sorozatát), és cookie-ként elküldi a böngészőnek a kért oldallal együtt.
Ezentúl a böngésző automatikusan elküldi a cookie-t a szervernek minden alkalommal, amikor új oldalt kér az oldalról. A szerver nem csak a szokásos módon elküldi az oldalt, hanem egy naplófájlban tárolja a kért oldal URL-jét, a kérés dátumát/időpontját és a cookie-t.
A naplófájl elemzésével meghatározhatja, hogy a felhasználó mely oldalakat, milyen sorrendben és mennyi ideig kereste fel.
Egyes műveletek, amelyekhez cookie-kat használnak, más mechanizmusok segítségével is végrehajthatók. Ezeknek az alternatíváknak azonban megvannak a hátrányai, amelyek a gyakorlatban néha előnyösebbé teszik a sütiket. Ezen alternatívák többsége lehetővé teszi a felhasználó nyomon követését, bár kevésbé megbízható módon, mint a cookie-k. Ennek eredményeként az adatvédelem még akkor is veszélyben marad, ha a böngésző letiltja a cookie-kat, vagy nem állítja be a szerver.
A felhasználók követésének ez a megbízhatatlan módszere az oldalakat megtekintő számítógépek IP-címeinek tárolásán alapul . Ez a technika a World Wide Web hajnala óta elérhető , és az oldal betöltéséhez az ügyfél IP-címének ismerete szükséges. Ezek az információk a szerveren tárolhatók, függetlenül attól, hogy használnak-e sütiket vagy sem.
Ez a módszer azonban kevésbé biztonságos, mint a cookie-k, mivel a számítógépek és a proxy-k megoszthatók több felhasználó között, és egy számítógép különböző IP-címeket használhat különböző munkamenetekben (dinamikus IP-cím).
Előfordulhat, hogy az IP-cím alapján történő nyomon követés nem lehetséges anonimitás-megőrző rendszerek (például Tor ) használata esetén. Az ilyen rendszerekben egy böngészőnek több IP-címe is lehet, és több felhasználó használhatja ugyanazt az IP-címet, ami lehetetlenné teszi az IP-cím nyomon követését.
Egyes nagyobb internetszolgáltatók, köztük az AOL , az összes webes forgalmat proxyhálózaton keresztül továbbítják , ami szintén használhatatlanná teszi ezt a módszert.
Egy fejlettebb technika az adatok URL-be való beágyazásán alapul. Ez általában lekérdezési karakterlánc használatával történik, de az URL más részei is használhatók. A JavaScript és a PHP széles körben használja ezeket a mechanizmusokat, amikor a cookie-k le vannak tiltva.
A webszerver egy lekérdezési karakterláncot ad egy weboldalra mutató hivatkozáshoz, amikor elküldi azt a böngészőnek. Amikor a felhasználó a hivatkozásra kattint, a böngésző egy lekérdezési karakterláncot küld vissza a szervernek.
Ebből a szempontból a lekérdezési karakterlánc és a cookie nagyon hasonlóak: a böngésző által visszaküldött szerverinformációk darabjai. Vannak azonban bizonyos különbségek: mivel a lekérdezési karakterlánc az URL része, az URL újrafelhasználásakor ugyanaz az információ kerül továbbításra a szerverre. Például, ha egy felhasználó beállításai egy URL-lekérdezési karakterláncban vannak kódolva, és a felhasználó elküldi ezt az URL-t egy másik felhasználónak, akkor ezek a beállítások a másik felhasználóra is érvényesek lesznek.
Ezen túlmenően, még ha a felhasználó többször is felkeresi ugyanazt az oldalt, nincs garancia arra, hogy a lekérdezési karakterlánc változatlan marad. Például amikor a webhely belső oldalairól és külső keresőmotorokból navigál, a lekérdezési karakterláncok eltérőek lesznek, míg a cookie-k ugyanazok maradnak.
A lekérdezési karakterlánc másik hátránya biztonsági szempontból adódik: a munkamenet azonosítójának a lekérdezési karakterláncban való tárolása megkönnyíti a támadást. Az azonosító cookie-ban való átadása biztonságosabb.
A munkamenet szerveroldali programmal való nyomon követésének egyik módja a rejtett mezőket tartalmazó webes űrlapok használata. Ez a módszer nagyon hasonlít az URL lekérdezési karakterlánchoz, és szinte ugyanazokkal az előnyökkel és hátrányokkal rendelkezik, és ha az űrlapparamétereket a HTTP GET metóduson keresztül küldi el, akkor a mezők valójában annak az URL-nek a részévé válnak, amelyet a böngésző elküld a szervernek. . A legtöbb űrlapot azonban a HTTP POST dolgozza fel , ahol az információ nem része sem az URL-nek, sem a cookie-nak.
Ennek a megközelítésnek két előnye van a követés szempontjából: egyrészt az információ beillesztése a HTML-kódba és a POST-ba, és nem az URL-be, azt jelenti, hogy az átlagos felhasználó egyszerűen nem veszi észre, másrészt a munkamenet információit nem másolják át. az URL másolásával (például amikor a felhasználó e-mailben linket küld). Ennek a módszernek az a hátránya, hogy a munkamenet-információkat a HTML kód tartalmazza, így a weboldalt minden alkalommal le kell generálni, amikor kérik, ami növeli a webszerver terhelését.
A HTTP protokoll alapvető hitelesítést és titkosítást tartalmaz, amely csak akkor teszi lehetővé az oldalhoz való hozzáférést, ha a felhasználó megadja a megfelelő felhasználónevet és jelszót. Ha a szerver ezt kéri, akkor a böngésző felveszi a kapcsolatot a felhasználóval, és miután megkapta a szükséges adatokat, elmenti és felhasználja más oldalak eléréséhez anélkül, hogy a felhasználónak újra meg kellene adnia azokat. A felhasználó szemszögéből nézve a hatás ugyanaz, mint a cookie használatakor: csak egyszer kell felhasználónév és jelszó megadása, majd a felhasználó hozzáférést kap az oldalhoz. Az alapszintű hitelesítéssel a felhasználónév/jelszó kombináció minden böngészőkéréssel titkosítás nélkül kerül elküldésre a szervernek. Ez azt jelenti, hogy ha valaki elfogja a forgalmat, megkaphatja ezt az információt, és ezt követően felhasználhatja. Titkosított hitelesítés esetén a felhasználónév és a jelszó titkosítása a szerver által generált véletlen kulccsal történik.
Egyes webböngészők lehetővé teszik egy oldal számára, hogy helyi információkat tároljon későbbi visszakeresés céljából. Az Internet Explorer például támogatja az információk tárolását az előzményekben, a kedvencekben , az XML -tárolókban, vagy lehetővé teszi a weboldal közvetlen lemezre mentését [43] .
A JSON Web Token (JWT) egy önálló információcsomag, amely a felhasználó identitásával és identitásával kapcsolatos információk tárolására használható. Ez lehetővé teszi, hogy a munkamenet cookie-k helyett használják őket. Ellentétben a cookie-kkal, amelyeket a böngésző automatikusan csatol minden HTTP-kéréshez, a webalkalmazásnak kifejezetten csatolnia kell a JWT-ket minden HTTP-kéréshez.
Minden modern webböngésző meglehetősen nagy mennyiségű adatot (2-32 MB) képes tárolni JavaScripten keresztül a window.name DOM tulajdonság használatával. Ezek az adatok a munkamenet-cookie-k helyett használhatók, és domainek közöttiek is. A technika kombinálható JSON/JavaScript objektumokkal a munkamenetváltozók összetett készleteinek tárolására [44] a kliens oldalon.
A webes gyorsítótár olyan információk tárolására is használható, amelyek segítségével nyomon követhető az egyes felhasználók. Ez a módszer azt a tényt használja ki, hogy a webböngésző a gyorsítótárban tárolt erőforrásokat használja ahelyett, hogy letöltené azokat a webhelyről, amikor megállapítja, hogy az erőforrás legfrissebb verziója már a gyorsítótárban van.
Például egy oldal tartalmazhat egy hivatkozást <script type="text/javascript" src="example.js">. A szkript egyedi azonosítót állít be a felhasználó számára (például var userId = 3243242;). Az első látogatás után minden alkalommal, amikor a felhasználó felkeresi az oldalt, ez a fájl a gyorsítótárból töltődik be, nem pedig a szerverről. Így a tartalma soha nem fog változni.
Ennek a módszernek az egyetlen előnye a több telephelyen végzett munka, amely lehetővé teszi a felhasználó jogosulatlan megfigyelését. Hátrányok - ezen információk nem triviális átvitele a szerverre és rendkívüli kezelhetetlenség: a böngésző bármikor elveszítheti a gyorsítótárazott adatokat, a beállításoktól, a memória méretétől és a lemezterülettől függően. A Mozilla Firefox 85+ nem teszi lehetővé a webhelyek közötti követést a gyorsítótáron keresztül [45] .
A legtöbb modern böngésző támogatja a cookie-kat, és lehetővé teszi a felhasználó számára ezek letiltását. A következő gyakori lehetőségek [46] :
| http | |
|---|---|
| Általános fogalmak |
|
| Mód | |
| Címek |
|
| Állapotkódok | |