A Discover biztonságos webalapú proxy-szolgáltatása – Facebook Engineering

Kapcsolati erőfeszítéseink középpontjában az internet-hozzáférés és az internet elterjesztése áll világszerte. Ez magában foglalja az olyan technológiákon végzett munkánkat, mint a Terragraph, a mobilszolgáltatókkal való együttműködésünket a vidéki hozzáférés kiterjesztésére irányuló erőfeszítésekben, a Telecom Infra Project keretében végzett munkánkat, valamint az olyan programokat, mint a Free Basics. A Free Basics programmal kapcsolatos munkánk során meghallgattuk a civil társadalom és más érdekelt felek visszajelzéseit és ajánlásait. Kifejezetten ezeknek az ajánlásoknak a kezelésére és beépítésére dolgoztuk ki a Discover-et egy új, a csatlakoztathatóságot támogató termékbe. A Facebook Connectivity és partnereink a Bitel, a Claro, az Entel és a Movistar ma indítják el a Discover próbaverzióját Peruban.

Nehéz technikai kihívás volt ezt a szolgáltatást úgy nyújtani, hogy közben az emberek biztonságban legyenek a potenciális biztonsági kockázatoktól. Olyan modellt akartunk kidolgozni, amely lehetővé teszi, hogy biztonságosan jelenítsük meg az összes elérhető domainről származó weboldalakat, beleértve azok erőforrásait (szkriptek, média, stíluslapok stb.). Az alábbiakban bemutatjuk az általunk épített modellt, az egyedi architektúrával kapcsolatos döntéseket, amelyeket az út során hoztunk, és a kockázatok csökkentése érdekében tett lépéseket.

Honnan indultunk

A Free Basics esetében az volt a kihívás, hogy megtaláljuk a módját annak, hogy ingyenesen nyújtsunk szolgáltatást azoknak, akik a mobil webet használják, akár olyan mobiltelefonokon is, amelyek nem támogatnak harmadik féltől származó alkalmazásokat. A mobilszolgáltatók partnerei nyújthatták volna a szolgáltatást, de a hálózati és átjáró-berendezések korlátai miatt csak bizonyos célállomásokra (általában IP-címtartományok vagy domainnevek listája) irányuló forgalom volt ingyenesen elérhető. Mivel világszerte több mint 100 partnerünk volt, és a szolgáltatói hálózati berendezések konfigurációjának megváltoztatása időigényes és nehézkes volt, rájöttünk, hogy új megközelítéssel kell előállnunk.

Az új megközelítéshez először egy webalapú proxy-szolgáltatást kellett létrehoznunk, ahol a szolgáltató ingyenesen elérhetővé tehette a szolgáltatást egyetlen domainre: freebasics.com. Onnan a felhasználó nevében lekérnénk a weboldalakat, és eljuttatnánk azokat a felhasználó készülékére. Még a modern böngészők esetében is vannak aggályok a webalapú proxy-architektúrákkal kapcsolatban. A weben az ügyfelek képesek kiértékelni az olyan biztonsági HTTP fejléceket, mint a CORS (cross-origin resource sharing) és a CSP (Content Security Policy), és közvetlenül a webhelyről használhatják a cookie-kat. Egy proxy-kiszolgáló konfigurációban azonban az ügyfél a proxyval lép kapcsolatba, a proxy pedig ügyfélként viselkedik a webhelyhez képest. A harmadik féltől származó webhelyek egyetlen névtéren keresztül történő közvetítése sért néhány feltételezést a sütik tárolásának módjával, a szkriptek tartalomolvasáshoz vagy -szerkesztéshez való hozzáférésének mértékével, valamint a CORS és a CSP értékelésének módjával kapcsolatban.

Az említett aggályok kezelése érdekében kezdetben néhány egyszerű korlátozást vezettünk be, többek között azt, hogy mely webhelyek látogathatók a Free Basics segítségével, és hogy nem lehet szkripteket futtatni. Ez utóbbi idővel egyre nagyobb problémát jelentett, mivel számos webhely, beleértve a mobiloldalakat is, elkezdett JavaScriptre támaszkodni a kritikus funkciókhoz, beleértve a tartalom megjelenítését is.

Eredeti architektúra

Domain design

A sok mobilszolgáltatói átjáró korlátozott funkcionalitásának figyelembevétele érdekében alternatív architektúrákat vettünk figyelembe, többek között:

1. Egy olyan kooperatív megoldást, amelyben a webhelyek egy aldomain-t (pl., free.example.com) és feloldják a mi IP-tartományunkban, hogy a szolgáltatók ingyenesen elérhetővé tegyék a felhasználó számára.

Ez a megoldás előnyei:

• Elérte a közvetlen végponttól végpontig tartó kommunikációt a kliens és a szerver között.
• Minimális beavatkozást igényelt a proxy oldalán.

Volt azonban néhány hátránya is:

• A webhelyeknek bele kellett egyezniük ebbe a rendszerbe, ami a webhelytulajdonosok számára további mérnöki költségeket jelentett.
• A böngészőknek egy adott tartományt kellett kérniük a Server Name Indication (SNI) segítségével, hogy a proxy tudja, hova kell csatlakozniuk. Az SNI támogatása azonban nem általános, ami ezt a megoldást kevésbé életképessé tette.
• Ha az előfizetők véletlenül közvetlenül a example.com, és nem a free.example.com aldomainre böngésznének, díjakat kellene fizetniük – és nem feltétlenül az aldomainre irányítanák át őket, hacsak a szolgáltató nem valósított meg valamilyen extra logikát.

1. IPv4-in-IPv6 kapszulázás, ahol a teljes IPv4 teret egyetlen szabad adat IPv6 alhálózaton belül tudjuk kapszulázni. Egy testreszabott DNS-feloldó ezután rekurzívan feloldja az IPv4-et, és kapszulázott IPv6-válaszokkal válaszol.

Ez a megoldás is rendelkezett előnyökkel:

• Nem igényelt együttműködést a weboldal tulajdonosától.
• Nem volt szükség SNI-re a távoli IP feloldásához.

És hátrányai:

• A böngészők látták a www.example.com.freebasics.com tartományt, de a www.example.com tanúsítvány hibát eredményezett.
• Már csak néhány fuvarozói átjáró támogatta az IPv6-ot ilyen módon.
• Még kevesebb eszköz támogatta az IPv6-ot, különösen a régebbi operációs rendszer verziók.

Egyik sem volt életképes megoldás. Végül úgy döntöttünk, hogy a lehető legjobb architektúra az origin collapsing lenne, ahol a proxy egyetlen origin collapsed domain névtérben fut az freebasics.com alatt. Az üzemeltetők így könnyebben engedélyezhetik az erre a célállomásra irányuló forgalmat, és egyszerűbbé tehetik a konfigurációjukat. Minden harmadik fél eredetét egy altartományba kódoljuk, így garantálni tudjuk, hogy a névfeloldás mindig egy szabad IP címre irányítja a forgalmat.

Például:

https://example.com/path/?query=value#anchor

Újraíródik:

https://https-example-com.0.freebasics.com/path/?query=value#anchor

Kiterjedt szerveroldali logika biztosítja, hogy a linkek és a hrefs helyesen alakuljanak át. Ugyanez a logika segít abban, hogy még a csak HTTP-s oldalakat is biztonságosan szállítsák HTTPS-en keresztül a Free Basics-on az ügyfél és a proxy között. Ez az URL-átírási séma lehetővé teszi, hogy egyetlen névteret és TLS-tanúsítványt használjunk, ahelyett, hogy az internet minden egyes aldomainjéhez külön tanúsítványra lenne szükség.

Az összes internetes eredet a 0.freebasics.com alatt testvérnévvé válik, ami bizonyos biztonsági megfontolásokat vet fel. Nem tudtuk kihasználni a tartomány hozzáadását a nyilvános utótaglistához, mivel minden eredethez más-más sütit kellett volna kiállítanunk, ami végül túllépné a böngészők süti-korlátjait.

Sütik

A webes kliensekkel ellentétben, amelyek közvetlenül a webhelyről használhatják a sütiket, a proxy-szolgáltatás más beállítást igényel. A Free Basics több okból is a szerveroldalon tárolja a felhasználói cookie-kat:

1. Az alacsonyabb szintű mobilböngészők gyakran korlátozott cookie-támogatással rendelkeznek. Ha a proxy tartományunk alatt akár csak egy sütit is kiadunk webhelyenként, akkor mindössze több tíz süti beállítására szorítkozhatunk. Ha a Free Basics minden egyes 0.freebasics.com alatti webhelyhez kliensoldali cookie-kat állítana be, a régebbi böngészők gyorsan elérnék a helyi cookie-tárolási korlátokat – és még a modern böngészők is elérnék a tartományonkénti korlátot.
2. A tartomány névterének korlátozása, amelyet meg kellett valósítanunk, szintén kizárta a testvéri és hierarchikus cookie-k használatát. Például egy bármelyik .example.com aldomainen beállított süti általában bármelyik másik aldomainen olvasható lenne. Más szóval, ha a.example.com beállít egy cookie-t .example.com-en, akkor b.example.com-nak képesnek kell lennie olvasni azt. A Free Basics esetében a a-example-com.0.freebasics.com cookie-t állítana be a example.com.0.freebasics.com-re, ami a szabvány szerint nem megengedett. Mivel ez nem működik, más eredetűek, például b-example-com.0.freebasics.com, nem tudnának hozzáférni a szülői tartományukhoz beállított cookie-khoz.

Azért, hogy a proxy szolgáltatás hozzáférhessen ehhez a szerveroldali cookie-tárolóhoz, a Free Basics két kliensoldali cookie-t használ:

1. A datr cookie, egy böngészőazonosító, amelyet a webhely integritására használnak.
2. A ick (internetes cookie-kulcs), amely a kiszolgálóoldali cookie-üveg titkosításához használt kriptográfiai kulcsot tartalmazza. Mivel ezt a kulcsot csak az ügyféloldalon tároljuk, a Free Basics nem tudja visszafejteni a kiszolgálóoldali cookie-tárolót, amikor a felhasználó nem használja a szolgáltatást.

A felhasználói adatvédelem és biztonság érdekében, amikor a cookie-kat a kiszolgálóoldali cookie-tárolóban tároljuk, gondoskodunk arról, hogy:

1. A kiszolgálóoldali cookie-kat egy ick-val titkosítjuk, amelyet csak az ügyfélnél tartunk.
2. Ha a kliens megadja a ick-t, azt a szerver minden egyes kérésnél elfelejti, anélkül, hogy azt valaha is naplózná.
3. A kliensoldali sütiket Secure-nak és HttpOnly-nek jelöljük.
4. A kliensoldali kulcs segítségével hash-eljük a cookie indexét, így a cookie nem követhető vissza a felhasználóhoz, ha a kulcs nincs jelen.

A szkriptek futtatásának engedélyezése a szerveroldali cookie-k rögzítését kockáztatja. Ennek megakadályozása érdekében kizárjuk a JavaScript használatát a Free Basicsból. Továbbá, bár bármely weboldal része lehet a Free Basics-nek, minden egyes webhelyet külön-külön vizsgálunk át a potenciális visszaélési vektorok szempontjából, függetlenül a tartalomtól.

Az általunk felépített rendszer továbbfejlesztése

A bármely webhelyet kiszolgáló modell támogatásához, amely biztonságosabban teszi lehetővé a szkriptek futtatását, jelentősen át kellett gondolnunk a felépítésünket, hogy megelőzzük a fenyegetéseket, például azt, hogy a szkriptek képesek legyenek akár olvasni, akár rögzíteni a felhasználó cookie-jait. A JavaScriptet rendkívül nehéz elemezni és megakadályozni a nem kívánt kód végrehajtását.

Példaként íme néhány mód, ahogyan egy támadó kódot juttathatna be, amelyet ki kellene tudnunk szűrni:

setTimeout();location = ' javascript:alert(1) <!--';location = 'javascript\n:alert(1) <!--';location = '\x01javascript:alert(1) <!--';var location = 'javascript:alert(1)';for(location in {'javascript:alert(1)':0}); = 'javascript:alert(1)';location.totally_not_assign=location.assign;location.totally_not_assign('javascript:alert(1)');location] = 'javascript:alert(1)';Reflect.set(location, 'href', 'javascript:alert(1)')new Proxy(location, {}).href = 'javascript:alert(1)'Object.assign(window, {location: 'javascript:alert(1)'});Object.assign(location, {href: 'javascript:alert(1)'});location.hash = '#%0a alert(1)';location.protocol = 'javascript:';

A modell, amellyel előálltunk, kibővítette a Free Basics tervét, de a titkosítási kulcsot tároló cookie-t is védi a szkriptek általi felülírástól. Egy külső keretet használunk, amelyben megbízunk, hogy igazolja, hogy a belső keretet, amely harmadik fél tartalmát mutatja be, nem manipulálják. A következő részben részletesen bemutatjuk, hogyan enyhítjük a munkamenet-rögzítést és más támadásokat, például az adathalászatot és a kattintáslopást. Bemutatunk egy módszert a harmadik féltől származó tartalmak biztonságos kiszolgálására, miközben lehetővé tesszük a JavaScript futtatását.

Architektúrafejlesztések a Discoverben

A domainre való hivatkozások ezen a ponton az új domainünkre, egy hasonlóan eredet-összeollózott discoverapp.com-re változnak.

JavaScript és a cookie-k rögzítése

A harmadik féltől származó oldalak JavaScriptjének engedélyezésével tudomásul kellett vennünk, hogy ez lehetővé tesz bizonyos vektorokat, amelyekre fel kellett készülnünk, mivel a szkriptek módosíthatják és átírhatják a linkeket, hozzáférhetnek a DOM bármely részéhez, és legrosszabb esetben rögzíthetik a kliensoldali cookie-kat.

Az általunk kidolgozott megoldásnak foglalkoznia kellett a cookie-k rögzítésével, így ahelyett, hogy megpróbálnánk elemezni és blokkolni bizonyos szkripthívásokat, úgy döntöttünk, hogy észleljük, amikor megtörténik, és használhatatlanná tesszük. Ezt a következőkkel érjük el:

1. A regisztrációkor egy új, biztonságos, véletlenszerű ick-t generálunk.
2. A ick-t egy HttpOnly cookie-ként küldjük a böngészőnek.
3. Ezután a ick és a datr digestjéből HMAC-olunk egy ickt nevű értéket (hogy elkerüljük a rögzítést mindkettőnél), és a ickt egy másolatát tároljuk a kliensen, a localStorage egy olyan helyén, ahová egy potenciális támadó nem tud írni. Az általunk használt hely a https://www.0.discoverapp.com, amely soha nem szolgál ki harmadik féltől származó tartalmat. Mivel ez az eredet minden harmadik féltől származó eredetnek testvére, nem történhet domain-leeresztés vagy bármilyen más domain-módosítás, és az eredet megbízhatónak tekinthető.
4. A kérésben látható ick cookie-ból származó ickt-t minden harmadik féltől származó proxy-válaszban a HTML-be ágyazzuk be.
5. Az oldal betöltésekor a window.postMessage() segítségével összehasonlítjuk a beágyazott ickt-et a megbízható ickt-vel, és eltérés esetén érvénytelenítjük a munkamenetet a datr és ick cookie-k törlésével.
6. Megakadályozzuk a felhasználó interakcióját az oldallal, amíg ez a folyamat be nem fejeződik.

Kiegészítő védelemként új datr sütit állítunk be, ha több sütit észlelünk ugyanazon a helyen, beágyazva egy időbélyeget, így mindig a legfrissebbet használhatjuk.

Kétkeretes megoldás

A validáláshoz szükségünk van egy olyan módra, amellyel egy harmadik fél oldala lekérdezheti a ickt értékét és validálhatja azt. Ezt úgy érjük el, hogy a harmadik fél oldalát beágyazzuk egy <iframe>-be a biztonságos eredetű oldalba, és beillesztünk egy darab JavaScriptet a harmadik fél oldalába. Felépítünk egy biztonságos külső keretet és egy harmadik féltől származó belső keretet.

Belső keret

A belső keretben egy szkriptet injektálunk minden általunk kiszolgált proxizált oldalba. A kérésben látott ick-ból számított ickt értéket is befecskendezzük vele együtt. A belső keret viselkedése a következő:

1. Ellenőrzés a külső kerettel:
   • postMessage to top with ickt embedded in the page.
   • Wait.
   • Ha a szkript visszaigazolást kap a biztonságos eredettől, hagyjuk, hogy a felhasználó interakcióba lépjen az oldallal.
   • Ha a szkript túl sokáig várakozik, vagy nem várt eredetről kap választ, akkor a keretet egy harmadik fél tartalmát nem tartalmazó hibaképernyőre navigáljuk (a “Hoppá” oldalunk), mert lehetséges, hogy a külső keret vagy nincs ott, vagy más, mint amire a belső keret számít.
2. Ellenőrzés a parent-vel:
   • postMessage a parent-hez.
   • Várunk.
   • Ha a szkript source===parent és .0.discoverapp.com alatti eredettel kap választ, akkor folytatja.
   • Ha a szkript túl sokáig vár, vagy váratlan eredetű választ kap, akkor a “Hoppá” oldalra navigálunk.

Néhány megjegyzés a belső kerettel kapcsolatban:

1. Még ha meg is kerüljük, a potenciális támadók csak olyan eredetre tudnának rögzíteni, amelyen kódfuttatást tudnak elérni, így a cookie-k rögzítési vektorai feleslegessé válnak.
2. Feltételezzük, hogy egy jóindulatú eredet nem fogja szándékosan megkerülni a belső-külső üzenetküldő protokollt.

Külső keret

A külső keret azért van, hogy tanúsítsa, hogy a belső keret konzisztens:

1. Meggyőződünk arról, hogy a külső keret mindig a felső keret a JavaScript és X-Frame-Options: DENY segítségével.
2. Várunk a postMessage-re.
3. Ha a külső keret üzenetet kap:
   • A belső keret eredetéről érkezik?
   • Ha igen, a helyes ickt értéket jelenti?
     • Ha igen, küldjünk nyugtázó üzenetet.
     • Ha nem, töröljük a munkamenetet, töröljük az összes sütit, és navigáljunk egy biztonságos eredetű helyre.
4. Ha a külső keret néhány másodpercig nem kap üzenetet, vagy az alkeret nem a legfelső belső keret, eltávolítjuk a helyet a biztonságos keret címsorából.

A lap interakciója

Az olyan versenyállapotok elkerülése érdekében, amikor egy személy egy rögzített süti alatt beírhat egy jelszót, mielőtt a belső keret befejezte volna az ellenőrzést, fontos megakadályozni, hogy az emberek interakcióba lépjenek az oldallal, mielőtt a belső keret ellenőrzési sorozata befejeződik.

Ennek megakadályozására a kiszolgáló minden oldal <html> eleméhez style="display:none"-et ad hozzá. A belső keret ezt eltávolítja, amikor megkapja a külső keret megerősítését.

A JavaScript kód továbbra is futtatható, és az erőforrások továbbra is lehívhatók. De mindaddig, amíg az illető nem adott be semmilyen adatot az oldalra, a böngésző nem tesz semmi olyat, amit egy potenciális támadó ne tehetett volna meg egyszerűen az oldal meglátogatásával – kivéve, ha az oldal már sebezhető a Cross-Site Request Forgery (CSRF) szempontjából.

Azzal, hogy ezt a megoldást választottuk, más lehetséges kimeneteleket is meg kellett oldanunk, nevezetesen:

1. Aszinkron cookie-fixálás.
2. Clickjacking a keretezés miatt.
3. Phishing, amely a Discover domainnek adja ki magát.

Aszinkron cookie-fixálás

Eddig a megvalósított védelmek a szinkron fixálásokat vették figyelembe, de ezek aszinkron is előfordulhatnak. Ennek megakadályozására egy klasszikus CSRF-megelőzési módszert alkalmazunk. Megköveteljük, hogy a POST-ok az oldal betöltésekor látott datr lekérdezési paramétert tartalmazzanak. Ezután összehasonlítjuk a lekérdezési paramétert a kérésben látott datr cookie-val. Ha nem egyeznek, nem teljesítjük a kérést.

A datr kiszivárgásának elkerülése érdekében a datr titkosított változatát beágyazzuk a belső keretbe, és biztosítjuk, hogy ez a lekérdezési paraméter minden <form> és XHR objektumhoz hozzá legyen adva. Mivel az oldal nem tudja magától levezetni a datr tokent, a hozzáadott datr az, amelyik éppen látható.

A névtelen kérések esetében megköveteljük, hogy azok is rendelkezzenek a datr lekérdezési paraméterrel. Az anonimitás megmarad, mert nem szivárogtatjuk ki a harmadik fél webhelyére – a ick cookie hiányzik, így nem tudjuk használni a cookie-edényt. Ebben az esetben azonban nem vagyunk képesek a datr cookie ellenében validálni, így az anonim POST-okat fixált munkamenetek alatt is el lehet végezni. De mivel ezek névtelenek és hiányzik a ick, nem szivároghatnak ki érzékeny információk.

Clickjacking

Ha egy webhely X-Frame-Options: DENY-t küld, az nem töltődik be egy belső keretbe. Ezt a fejlécet a webhelyek arra használják, hogy megakadályozzák bizonyos típusú támadásoknak, például a clickjackingnek való kitettséget. Eltávolítjuk ezt a fejlécet a HTTP-válaszból, de megkérjük a belső keretet, hogy a postMessage segítségével ellenőrizze, hogy az parent a top ablakkeret. Ha az érvényesítés sikertelen, a felhasználót a “Hoppá” oldalra navigáljuk.

Phishing

A biztonságos keretben biztosított “címsor” arra szolgál, hogy a legfelső belső keret eredetét felfedje a felhasználó előtt. Ezt azonban lemásolhatják a Discover-et megszemélyesítő adathalász oldalak. A <iframe sandbox> segítségével megakadályozzuk, hogy a rosszindulatú linkek elnavigáljanak a Discoverről a felső navigáció megakadályozásával. A külső keretből csak egy másik webhelyre való közvetlen navigálással lehet kikerülni.

Kliensoldali sütik

A document.cookie lehetővé teszi a JavaScript számára, hogy olvassa és módosítsa a nem HttpOnly jelölésű sütiket. Ennek biztonságos támogatása kihívást jelent egy olyan rendszerben, amely a cookie-kat a kiszolgálón tartja fenn.

A cookie-k elérése: Amikor egy kérés érkezik, a proxy felsorolja az összes olyan sütit, amely az adott eredet számára látható. Ezután egy JSON hasznos terhet csatol a válaszoldalhoz. Az ügyféloldali kódot a document.cookie shim document.cookie befecskendezi, és ezeket a cookie-kat láthatóvá teszi más szkriptek számára, mintha valódi ügyféloldali cookie-k lennének.

Sütik módosítása:

A böngésző CORS-képességeiben való bizalom ebben az esetben nem lenne elég – a a.example.com eredet example.com-en cookie-t próbál beállítani, a böngésző blokkolni fogja, mivel ezek az eredetek testvérek és nem hierarchikusak.

Még így is, amikor a kiszolgáló megkapja az ügyfél által beállított új cookie-t, nem tudja biztonságosan érvényesíteni, hogy a céltartomány engedélyezett-e. Az író eredete csak az ügyfélnél ismert, és nem mindig úgy küldi el a kiszolgálónak, hogy megbízhatunk benne.

Az ügyfél kényszerítésére, hogy bizonyítsa, jogosult egy adott tartományban cookie-kat beállítani, a kiszolgáló a JSON hasznos teher mellett egy listát küld a kriptográfiai tokenekről minden olyan eredethez, ahol a kérő eredetnek engedélyezett a cookie-k beállítása. Ezek a tokenek a ick értékkel vannak sózva, így nem továbbíthatók a felhasználók között.

A document.cookie kliensoldali shim gondoskodik a token feloldásáról és beágyazásáról a proxynak küldött tényleges cookie-szövegbe. A proxy ezután ellenőrizni tudja, hogy az író eredet valóban birtokában van-e a token, hogy a cookie céltartományába írjon, és tárolja azt a kiszolgálóoldali cookie-edényben, és az oldal következő kérésekor újra elküldi az ügyfélnek.

Bootstrap protokoll

A modell három eredet típust tartalmaz: portál eredet (Discover portal stb.), biztonságos eredet (külső keret) és újraíró eredet (belső keret). Mindegyiknek más-más igénye van:

1. A portál eredethez datr.
2. A biztonságos eredethez ickt.
3. Az újraírási eredethez datr és ick szükséges.

LocalStorage protokollal

Itt van a legtöbb modern mobil böngésző bootstrap folyamatának ábrázolása:

Fontos megjegyezni, hogy a tükrözés elkerülése érdekében a biztonságos eredet bootstrap végpontja mindig új ick és ickt-t ad ki; a ick soha nem függ a felhasználói bemenettől. Vegyük észre, hogy mivel a ick-ra és a datr-ra is domain=.discoverapp.com-t állítottunk be, ezek minden eredettípusban elérhetőek, a ickt pedig csak a biztonságos eredeten érhető el.

LocalStorage protokoll nélkül

Mivel bizonyos böngészők, például az Opera Mini (népszerű számos országban, ahol a Discover működik) nem támogatja a localStorage-t, nem tudjuk tárolni a ick és ickt értékeket. Ez azt jelenti, hogy más protokollt kell használnunk:

Az újraírási eredet és a biztonságos eredet szétválasztása mellett döntöttünk, hogy a nyilvános utótaglistának megfelelően ne használják ugyanazt a hoszt-utótagot. A ickt biztonságos másolatának tárolására www.0.discoverapp.com-ot használunk (cookie-ként), és az összes harmadik fél eredetét 0.i.org alá helyezzük át. Egy jól viselkedő böngészőben a cookie beállítása a biztonságos eredetre elérhetetlenné teszi azt az összes újraíró eredet számára.

Mivel az eredeteket mostantól különválasztjuk, a bootstrap folyamatunk kétlépcsős lesz. Korábban beállíthattuk a ick-t ugyanabban a kérésben, amelyben a localStorage-t a ickt-gyel biztosítjuk. Most két origót kell bootstrapolnunk, külön kérésekben, anélkül, hogy ick rögzítési vektorokat nyitnánk.

Ezt úgy oldjuk meg, hogy először a biztonságos origót bootstrapoljuk a ickt cookie-val, és a felhasználónak megadjuk a ick titkosított változatát, egy csak a proxy által ismert kulccsal. A ick rejtjelezett szöveghez tartozik egy nonce, amely az adott ick visszafejtésére használható az újraíró eredetben, és a cookie beállítására, de csak egyszer.

A támadó választhat, hogy:

1. A nonce-t használja a ick cookie felfedésére.
2. Adja át a felhasználónak, hogy rögzítse az értékét.

A támadó egyik esetben sem tud egyszerre egy adott ick értéket megismerni és rákényszeríteni a felhasználóra. A folyamat szinkronizálja datr az eredeteket is.

Ez az architektúra jelentős belső és külső biztonsági tesztelésen ment keresztül. Úgy gondoljuk, hogy olyan konstrukciót fejlesztettünk ki, amely elég robusztus ahhoz, hogy ellenálljon a vadonban tapasztalt webalkalmazás-típusú támadásoknak, és biztonságosan biztosítsa a mobilszolgáltatók számára fenntartható összeköttetést. A Discover perui bevezetését követően további Discover-kísérleteket tervezünk partnerüzemeltetőkkel számos más országban, ahol már bétateszteltük a termékfunkciókat, többek között Thaiföldön, a Fülöp-szigeteken és Irakban. Várhatóan a Discover az elkövetkező hetekben ezekben a további országokban is élesben fog működni, és további kísérleteket fogunk vizsgálni, ahol a partnerüzemeltetők részt kívánnak venni.

Megköszönjük Berk Demirnek a munkában nyújtott segítségét.

Azért, hogy nyelvezetünk befogadóbb legyen, a “whitelist” helyett az “allowlist” kifejezéssel helyettesítettük ezt a bejegyzést.