Még a Google sem volt elég erős ahhoz, hogy megszabadítson bennünket a cookie-któl. Bő hete hivatalosan is bejelentették, amit egy ideje mindenki sejtett-tudott: továbbra is engedélyezik a harmadik féltől származó sütiket. De hogy a káposzta is megmaradjon: "egy új élménnyel" gazdagítják a böngészőt. Csak az nem derült ki, hogy mi is lenne ez az élmény.

A héten kiadott frissítőcsomagban azonban a hibajavítások mellett megjelent egy a sütik biztonságával összefüggő újdonság. Igaz, klasszikus informatikai értelemben nem igazán lehetne élménynek titulálni, mert minden a háttérben történik.

És hogy miért kell védeni a sütiket? Ha a támadó megszerzi a felhasználó valamelyik munkamenethez kapcsolódó cookie-jait, azok segítségével eltérítheti a munkamenetet, jogosulatlanul hozzáférhet a felhasználó fiókjához, sőt azt akár el is lophatja, hogy eladja a feketepiacon. A sütik többsége rövid életű, így nehéz kihasználni támadáshoz, de vannak kivételek, melyek korábban már okoztak súlyos incidenseket. Ezért erősíti meg védelmüket a keresőcég az alkalmazásokhoz kötött cookie-titkosítással (app-bound encryption).

Kitiltás helyett titkosít

A Google többféle módszerrel próbál védekezni a sütikre épülő támadási vektorokkal szemben. Tavasszal élesítette a Chrome-ban az eszközhöz kötött munkamenet-sütiket. Így a lopott sütiket a támadók más eszközön nem tudták használni. Ennek jó kiegészítése lesz a most bevezetett alkalmazáshoz kötött titkosítás.

Az újdonságot bemutató blogposztban a Chrome biztonsági csapatának vezető szoftvermérnöke, Will Harris azt írja, hogy minden platformon az operációs rendszer nyújtotta legbiztonságosabb titkosítási módszert használták. Ez MacOS-en a Keychain, Linuxon az adott disztribúció biztosította wallet, például a kwallet vagy a gnome-libsecret, Windowson pedig az adatvédelmi API-ra (DPAPI) építettek egy a MacOS védelmével azonos erősségű megoldást.

Az eljárás egy kiemelt jogosultságokkal rendelkező szolgáltatásra támaszkodik, amikor a kérelmet küldő alkalmazás identitását ellenőrzi. Az app-bound titkosítás kódolja az alkalmazás azonosítóját a titkosított adatokba, majd visszafejtéskor ellenőrzi annak érvényességét. Ha a rendszerben egy másik alkalmazás próbálja visszafejteni ugyanazokat az adatokat, akkor az fennakad az ellenőrzésen, és sikertelen lesz a dekódolás.

Mivel az app-bound titkosítás kiemelt jogosultságokkal fut, a sikeres támadáshoz az kevés, ha a támadók ráveszik a felhasználót, hogy indítson el egy rosszindulatú alkalmazást. A rosszindulatú programnak is kiemelt jogosultságot kell szereznie, vagy valamilyen módon a Chrome-ba kell bejuttatnia kódot. Utóbbit azonban a legitim szoftverek nem csinálják, így a vírusvédelem nagy valószínűséggel ki is szúrja a támadási kísérletet.

Üzleti környezetben csak kompromisszumokkal

Az app-bound titkosítás mutat némi rokonságot az eszközhöz kötött munkamenet-cookie-kkal, mivel a használt titkosítási kulcs is erősen kötődik a felhasználó gépéhez. Emiatt azonban üzleti környezetben, ahol sokan használnak több eszközt, és a munkameneteiket át is viszik ezek között, nem igazán használható az eljárás.

A Google a módszert más területen, például a hitelesítési tokenek, jelszavak és fizetési adatok védelménél is hasznosítani szeretné.