Onze inspanningen op het gebied van connectiviteit richten zich op het uitbreiden van internettoegang en -adoptie over de hele wereld. Dit omvat ons werk aan technologieën zoals Terragraph, onze samenwerking met mobiele operators om de toegang op het platteland uit te breiden, ons werk als onderdeel van het Telecom Infra Project, en programma’s zoals Free Basics. Terwijl we verder werkten aan Free Basics, hebben we geluisterd naar feedback en aanbevelingen van maatschappelijke organisaties en andere belanghebbenden. We hebben Discover speciaal ontwikkeld om die aanbevelingen aan te pakken en te verwerken in een nieuw product dat connectiviteit ondersteunt. Vandaag lanceren Facebook Connectivity en onze partners bij Bitel, Claro, Entel en Movistar een proef van Discover in Peru.

Het aanbieden van deze dienst en tegelijkertijd mensen beschermen tegen potentiële veiligheidsrisico’s was een lastige technische uitdaging. We wilden een model ontwikkelen waarmee we webpagina’s van alle beschikbare domeinen veilig konden presenteren, inclusief hun bronnen (scripts, media, stylesheets, enz.). Hieronder lopen we door het model dat we hebben gebouwd, de unieke architectuurkeuzes die we onderweg hebben gemaakt en de stappen die we hebben ondernomen om de risico’s te beperken.

Waar we begonnen

Voor Free Basics was het onze uitdaging om een manier te vinden om een gratis service te bieden aan mensen die het mobiele web gebruiken, zelfs op functietelefoons zonder ondersteuning van apps van derden. Partners van mobiele aanbieders konden de dienst leveren, maar beperkingen van het netwerk en de gateway-apparatuur betekenden dat alleen verkeer naar bepaalde bestemmingen (meestal IP-adresbereiken of een lijst met domeinnamen) gratis kon worden gemaakt. Met meer dan 100 partners wereldwijd en de tijd en moeite die het kost om de configuraties van de netwerkapparatuur van de carrier te veranderen, realiseerden we ons dat we met een nieuwe aanpak moesten komen.

Die nieuwe aanpak vereiste van ons dat we eerst een webgebaseerde proxy-dienst zouden bouwen waarbij de operator de service gratis beschikbaar kon maken voor één enkel domein: freebasics.com. Van daaruit zouden we webpagina’s ophalen namens de gebruiker en ze op hun apparaat afleveren. Zelfs op moderne browsers zijn er enkele bezwaren tegen webgebaseerde proxy-architecturen. Op het web kunnen clients beveiligde HTTP-headers evalueren, zoals cross-origin resource sharing (CORS) en Content Security Policy (CSP), en direct vanaf de site gebruik maken van cookies. Maar in een proxyserverconfiguratie interageert de client met de proxy, en fungeert de proxy als client naar de site. Het proxen van websites van derden via een enkele namespace is in strijd met enkele aannames over hoe cookies worden opgeslagen, hoeveel toegang scripts hebben om inhoud te lezen of te bewerken, en hoe CORS en CSP worden geëvalueerd.

Om aan deze zorgen tegemoet te komen, hebben we aanvankelijk enkele eenvoudige beperkingen opgelegd, waaronder welke sites met Free Basics konden worden bezocht en de onmogelijkheid om scripts uit te voeren. Dit laatste is in de loop der tijd een groter probleem geworden, aangezien veel websites, waaronder mobiele sites, JavaScript zijn gaan gebruiken voor kritieke functionaliteit, waaronder het renderen van inhoud.

Early architecture

Domain design

Om tegemoet te komen aan de beperkte functionaliteit van veel gateways van mobiele providers, hebben we alternatieve architecturen overwogen, waaronder:

  1. Een coöperatieve oplossing waarbij websites een subdomein kunnen toewijzen (bijv, free.example.com) kunnen toewijzen en deze kunnen omzetten naar onze IP-ruimte, zodat de exploitanten deze gratis aan de gebruiker kunnen aanbieden.

Deze oplossing had voordelen:

  • Het maakte directe end-to-end communicatie tussen client en server mogelijk.
  • Het vereiste minimale tussenkomst aan de proxy-zijde.

Het had echter ook enkele nadelen:

  • Sites moesten voor deze regeling kiezen, wat extra technische kosten voor site-eigenaren met zich meebracht.
  • Browsers zouden een specifiek domein moeten aanvragen via Server Name Indication (SNI), zodat de proxy zou weten waar hij verbinding moest maken. SNI wordt echter niet overal ondersteund, waardoor deze oplossing minder levensvatbaar is.
  • Als abonnees per ongeluk rechtstreeks naar example.com zouden surfen, in plaats van naar het subdomein free.example.com, zouden ze kosten moeten betalen – en ze zouden niet noodzakelijk naar het subdomein worden omgeleid, tenzij de exploitant extra logica had geïmplementeerd.
  1. IPv4-in-IPv6-encapsulatie, waarbij we de volledige IPv4-ruimte kunnen inkapselen in een enkel vrij data IPv6-subnet. Een aangepaste DNS-oplosser lost dan IPv4 recursief op en antwoordt met ingekapselde IPv6-antwoorden.

Deze oplossing had ook voordelen:

  • Het vereiste geen medewerking van de eigenaar van de website.
  • Er was geen noodzaak voor SNI om het IP op afstand op te lossen.

En nadelen:

  • Browsers zouden het www.example.com.freebasics.com domein zien, maar het www.example.com certificaat zou resulteren in een fout.
  • Nauwelijks een paar carriers gateways ondersteunden IPv6 op deze manier.
  • Even minder apparaten ondersteunden IPv6, vooral oudere OS-versies.

Geen van beide was een levensvatbare oplossing. Uiteindelijk hebben we besloten dat de best mogelijke architectuur origin collapsing zou zijn, waarbij onze proxy draait binnen een enkele origin-collapsed domain namespace onder freebasics.com. Operatoren kunnen dan gemakkelijker verkeer naar deze bestemming toestaan en hun configuraties eenvoudig houden. Elke herkomst van een derde partij is gecodeerd in een subdomein, zodat we kunnen garanderen dat naamresolutie het verkeer altijd naar een vrij IP leidt.

Voorbeeld:

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

wordt herschreven tot:

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

Er is uitgebreide server-side logica aanwezig om ervoor te zorgen dat links en href’s correct worden getransformeerd. Deze zelfde logica zorgt ervoor dat zelfs HTTP-only sites veilig worden afgeleverd via HTTPS op Free Basics tussen de client en de proxy. Dit URL-herschrijfschema stelt ons in staat om een enkele naamruimte en TLS-certificaat te gebruiken, in plaats van een apart certificaat voor elk subdomein op het internet nodig te hebben.

Alle internet origins worden broers en zussen onder 0.freebasics.com, wat bepaalde veiligheidsoverwegingen met zich meebrengt. We konden niet profiteren van het toevoegen van het domein aan de Public Suffix List, omdat we dan voor elke oorsprong een ander cookie zouden moeten uitgeven, wat uiteindelijk de cookie-limieten van de browser zou overschrijden.

Cookies

In tegenstelling tot webclients, die direct vanaf de site gebruik kunnen maken van cookies, vereist de proxy-dienst een andere opzet. Free Basics slaat cookies van gebruikers om verschillende redenen aan de serverzijde op:

  1. Downlevel mobiele browsers hebben vaak beperkte cookie-ondersteuning. Als we zelfs maar één cookie per site onder ons proxy-domein plaatsen, zouden we beperkt kunnen worden tot het plaatsen van slechts enkele tientallen cookies. Als Free Basics client-side cookies zou plaatsen voor elke site onder 0.freebasics.com, zouden oudere browsers snel de lokale opslaglimieten voor cookies bereiken – en zelfs moderne browsers zouden een per-domein limiet bereiken.
  2. De domeinnaamruimte beperkingen die we moesten implementeren sloten ook het gebruik van sibling en hiërarchische cookies uit. Bijvoorbeeld, een cookie ingesteld op een subdomein op .example.com zou normaal leesbaar zijn op elk ander subdomein. Met andere woorden, als a.example.com een cookie instelt op .example.com, dan zou b.example.com het moeten kunnen lezen. In het geval van Free Basics zou a-example-com.0.freebasics.com een cookie plaatsen op example.com.0.freebasics.com, wat volgens de standaard niet is toegestaan. Aangezien dat niet werkt, zouden andere origins, zoals b-example-com.0.freebasics.com, geen toegang hebben tot cookies die zijn ingesteld voor hun bovenliggende domein.

Om de proxy-dienst toegang te geven tot deze server-side cookie-pot, maakt Free Basics gebruik van twee client-side cookies:

  1. De datr cookie, een browser-identifier die wordt gebruikt voor site-integriteitsdoeleinden.
  2. De ick (internet cookie key), die een cryptografische sleutel bevat die wordt gebruikt om de server-side cookie jar te versleutelen. Aangezien deze sleutel alleen aan de kant van de client wordt opgeslagen, kan de server-side cookie jar niet worden gedecodeerd door Free Basics wanneer de gebruiker de service niet gebruikt.

Om de privacy en veiligheid van de gebruiker te helpen beschermen bij het opslaan van hun cookies in een server-side cookie jar, zorgen we ervoor dat:

  1. Server-side cookies worden gecodeerd met een ick die alleen op de client wordt bewaard.
  2. Wanneer de client de ick verstrekt, wordt deze bij elk verzoek door de server vergeten zonder ooit te worden gelogd.
  3. We markeren beide client-side cookies als Secure en HttpOnly.
  4. We hashen de index van een cookie met behulp van de client-side sleutel, zodat de cookie niet herleidbaar is naar de gebruiker wanneer de sleutel niet aanwezig is.

Het toestaan van scripts om te draaien riskeert de fixatie van server-side cookies. Om dit te voorkomen, sluiten we het gebruik van JavaScript uit van Free Basics. Bovendien, hoewel elke website deel kan uitmaken van Free Basics, beoordelen we elke site afzonderlijk op potentiële misbruikvectoren, ongeacht de inhoud.

Verbeteren wat we hadden gebouwd

Om een model te ondersteunen dat elke website bedient, met de mogelijkheid om scripts veiliger uit te voeren, moesten we onze architectuur aanzienlijk heroverwegen om bedreigingen te voorkomen, zoals scripts die in staat zijn om ofwel de cookies van de gebruiker te lezen of te fixeren. JavaScript is uiterst moeilijk te analyseren en te voorkomen dat onbedoelde code wordt uitgevoerd.

Als voorbeeld zijn hier enkele manieren waarop een aanvaller code zou kunnen injecteren die we zouden moeten kunnen filteren:

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:';

Het model dat we bedachten, breidde het Free Basics-ontwerp uit, maar het beschermt ook het cookie dat de coderingssleutel opslaat tegen overschrijven door scripts. We gebruiken een buitenste frame dat we vertrouwen om te bevestigen dat er niet wordt geknoeid met het binnenste frame, dat inhoud van derden presenteert. De volgende sectie laat in detail zien hoe we sessie-fixatie en andere aanvallen, zoals phishing en clickjacking, tegengaan. We leggen een methode uit om op een veilige manier inhoud van derden te serveren en tegelijkertijd de uitvoering van JavaScript mogelijk te maken.

Architectuurverbeteringen in Discover

Verwijzingen naar het domein op dit punt zullen veranderen in ons nieuwe domein, een vergelijkbaar origin-collapsed discoverapp.com.

JavaScript en cookie-fixatie

Door JavaScript van sites van derden toe te staan, hebben we moeten erkennen dat dit bepaalde vectoren mogelijk maakt waarop we ons moesten voorbereiden, aangezien scripts links kunnen wijzigen en herschrijven, toegang kunnen krijgen tot elk deel van het DOM, en, in het ergste geval, client-side cookies kunnen fixeren.

De oplossing die we bedachten moest cookie fixatie aanpakken, dus in plaats van te proberen om bepaalde script aanroepen te parsen en te blokkeren, besloten we om het te detecteren als het gebeurt en het nutteloos te maken. Dit wordt bereikt door het volgende:

  1. Bij het aanmelden genereren we een nieuwe, veilige willekeurige ick.
  2. We sturen ick naar de browser als een HttpOnly cookie.
  3. We HMAC-en dan een waarde genaamd ickt van een digest van zowel ick en datr (om fixatie voor beide te voorkomen) en slaan een kopie van ickt op de client op, op een locatie in localStorage waar een potentiële aanvaller niet naar kan schrijven. De locatie die we gebruiken is https://www.0.discoverapp.com, die nooit inhoud van derden serveert. Aangezien deze bron verwant is aan alle bronnen van derden, kan domeinverlaging of enige andere vorm van domeinwijziging niet plaatsvinden, en wordt de bron als vertrouwd beschouwd.
  4. We sluiten ickt, afgeleid van het ick-cookie dat in het verzoek wordt gezien, in de HTML in elk proxy-antwoord van een derde partij in.
  5. Wanneer de pagina wordt geladen, vergelijken we de ingesloten ickt met de vertrouwde ickt met behulp van window.postMessage(), en maken de sessie ongeldig als er een mismatch is door het verwijderen van de datr en ick cookies.
  6. We voorkomen interactie van de gebruiker met de pagina totdat dit proces is voltooid.

Als extra bescherming zetten we een nieuw datr cookie als we meerdere cookies op dezelfde locatie detecteren, waarbij we een tijdstempel insluiten zodat we altijd de meest recente kunnen gebruiken.

Twee-frames oplossing

Voor validatie hebben we een manier nodig voor een pagina van een derde partij om de ickt waarde op te vragen en deze te valideren. We doen dit door de site van derden in te bedden in een <iframe> in een pagina op de beveiligde oorsprong en een stukje JavaScript in de site van derden te injecteren. We bouwen een veilig buitenframe en een binnenframe van derden.

Binnenframe

In het binnenframe injecteren we een script in elke proxied pagina die we serveren. We injecteren ook de ickt waarde, berekend uit de ick die we in het verzoek zien, mee. Het gedrag van het binnenste frame is als volgt:

  1. Controle met buitenste frame:
    • postMessage naar boven met ickt ingebed in de pagina.
    • Wacht.
    • Als het script een bevestiging krijgt van de beveiligde oorsprong, laten we de gebruiker interacteren met de pagina.
    • Als het script te lang wacht of een antwoord krijgt van een onverwachte oorsprong, navigeren we het frame naar een foutscherm zonder inhoud van derden (onze “Oeps”-pagina), omdat het mogelijk is dat het buitenste frame er niet is of anders is dan het binnenste frame verwacht.
  2. Controleer met parent:
    • postMessage naar parent.
    • Wacht.
    • Als het script een antwoord krijgt met source===parent en herkomst onder .0.discoverapp.com, gaat het verder.
    • Als het script te lang wacht, of een antwoord krijgt van een onverwachte herkomst, navigeren we naar de “Oops”-pagina.

Enige opmerkingen over het binnenste frame:

  1. Zelfs als het wordt omzeild, zouden potentiële aanvallers in staat zijn om zich alleen te fixeren op een oorsprong waarop ze code-uitvoering kunnen bereiken, waardoor cookie-fixatievectoren overbodig worden.
  2. We gaan ervan uit dat een goedaardige oorsprong het binnen-buiten-berichtenprotocol niet opzettelijk zal omzeilen.

Buitenste frame

Het buitenste frame is er om te attesteren dat het binnenste frame consistent is:

  1. We zorgen ervoor dat het buitenste frame altijd het bovenste frame is met JavaScript en X-Frame-Options: DENY.
  2. Wacht op postMessage.
  3. Als het buitenste frame een bericht ontvangt:
    • Is het van een binnenste frame oorsprong?
    • Zo ja, rapporteert het de juiste ickt waarde?
      • Zo ja, stuur een bevestigingsbericht.
      • Zo nee, verwijder de sessie, verwijder alle cookies, en navigeer naar een veilige oorsprong.
  4. Als het buitenste frame gedurende een paar seconden geen bericht ontvangt of het subframe niet het bovenste binnenste frame is, verwijderen we de locatie uit de adresbalk van het veilige frame.

Pagina-interactie

Om race-condities te voorkomen waarbij een persoon een wachtwoord zou kunnen invoeren onder een gefixeerd cookie voordat het binnenste frame de verificatie heeft voltooid, is het belangrijk om te voorkomen dat mensen interactie hebben met de pagina voordat de verificatiesequentie van het binnenste frame is voltooid.

Om dit te voorkomen, voegt de server style="display:none" toe aan het <html> element van elke pagina. Het binnenste frame zal het verwijderen wanneer het de bevestiging van het buitenste frame krijgt.

JavaScript code mag nog steeds worden uitgevoerd, en bronnen worden nog steeds opgehaald. Maar zolang de persoon geen invoer op de pagina heeft ingevoerd, doet de browser niets wat een potentiële aanvaller niet had kunnen doen door simpelweg de site te bezoeken – tenzij de site al kwetsbaar is voor cross-site request forgery (CSRF).

Door voor deze oplossing te kiezen, moesten we andere mogelijke uitkomsten oplossen, met name:

  1. Asynchrone cookie-fixatie.
  2. Clickjacking als gevolg van framing.
  3. Phishing die zich voordoet als het Discover-domein.

Asynchrone cookie-fixatie

Tot nu toe hebben de beveiligingen die we hebben geïmplementeerd rekening gehouden met synchrone fixaties, maar ze kunnen ook asynchroon optreden. Om dit te voorkomen, gebruiken we een klassieke CSRF preventie methode. We vereisen dat POST’s een queryparameter bevatten met de datr die te zien is wanneer de pagina geladen wordt. Vervolgens vergelijken we de queryparameter met het datr-cookie dat in het verzoek is gezien. Als ze niet overeenkomen, voldoen we niet aan het verzoek.

Om te voorkomen dat datr uitlekt, sluiten we een versleutelde versie van de datr in het binnenste frame in en zorgen we ervoor dat deze queryparameter aan elk <form> en XHR object wordt toegevoegd. Aangezien de pagina het datr-token niet zelf kan afleiden, is de toegevoegde datr degene die op dat moment wordt gezien.

Voor anonieme verzoeken vereisen we dat ze ook de datr-queryparameter hebben. De anonimiteit blijft behouden omdat we het niet lekken naar de site van de derde partij – de ick cookie ontbreekt, dus we kunnen de cookiepot niet gebruiken. In dit geval zijn we echter niet in staat om te valideren tegen de datr cookie, dus anonieme POSTs kunnen worden gemaakt onder gefixeerde sessies. Maar omdat ze anoniem zijn en de ick missen, kan er geen gevoelige informatie uitlekken.

Clickjacking

Wanneer een site X-Frame-Options: DENY verzendt, zal deze niet in een inner frame laden. Deze header wordt door websites gebruikt om blootstelling aan bepaalde soorten aanvallen, zoals clickjacking, te voorkomen. We verwijderen deze header uit het HTTP antwoord, maar vragen het binnenste frame om te verifiëren dat parent het top window frame is met behulp van postMessage. Als de validatie mislukt, navigeren we de gebruiker naar de “Oops” pagina.

Phishing

De “adresbalk” die we in het beveiligde frame plaatsen, wordt gebruikt om de oorsprong van het bovenste binnenframe aan de gebruiker te laten zien. Het kan echter worden gekopieerd door phishing sites die zich voordoen als Discover. We voorkomen dat kwaadwillende links wegnavigeren van Discover door de bovenste navigatie te verhinderen met <iframe sandbox>. Het buitenste frame kan alleen worden omzeild door rechtstreeks naar een andere site te navigeren.

Client-side cookies

Met document.cookie kan JavaScript cookies lezen en wijzigen die niet met HttpOnly zijn gemarkeerd. Het is een uitdaging om dit veilig te ondersteunen in een systeem dat de cookies op de server bewaart.

Toegang tot cookies: Wanneer een verzoek wordt ontvangen, zal de proxy een opsomming maken van alle cookies die zichtbaar zijn voor die herkomst. Het zal dan een JSON payload toevoegen aan de antwoordpagina. Client-side code wordt geïnjecteerd om document.cookie te shimmen en deze cookies zichtbaar te maken voor andere scripts, alsof het echte client-side cookies zijn.

Wijziging van cookies: Als scripts willekeurig cookies mogen instellen die de server vervolgens accepteert, zou dit kunnen leiden tot fixatie, waarbij oorsprong evil.com een gevoelige cookie zou kunnen instellen op example.com.

Trouwen op de CORS-mogelijkheden van de browser zou in dit geval niet voldoende zijn – oorsprong a.example.com die probeert een cookie in te stellen op example.com zal door de browser worden geblokkeerd, aangezien deze oorsprongsgebieden broers en zussen zijn en niet hiërarchisch zijn.

En toch, wanneer de server een nieuw cookie ontvangt dat door de client is gezet, kan hij niet veilig afdwingen of het doeldomein is toegestaan; de oorsprong van de schrijver is alleen bekend op de client en wordt niet altijd naar de server gestuurd op een manier die we kunnen vertrouwen.

Om de client te dwingen te bewijzen dat hij in aanmerking komt om cookies op een specifiek domein te zetten, stuurt de server, naast de JSON payload, een lijst van cryptografische tokens voor elk van de oorsprongen waar de aanvragende oorsprong cookies mag zetten. Deze tokens zijn gezouten met de ick waarde, zodat ze niet kunnen worden overgedragen tussen gebruikers.

De client-side shim voor document.cookie zorgt voor het oplossen en insluiten van het token in de eigenlijke cookietekst die naar de proxy wordt gestuurd. De proxy kan dan verifiëren dat de schrijvende oorsprong inderdaad het token bezat om naar het doeldomein van de cookie te schrijven, en slaat het op in de server-side cookie jar, en stuurt het de volgende keer dat de pagina wordt opgevraagd weer naar de client.

Bootstrap protocol

Het model bevat drie oorsprong typen: portal oorsprong (Discover portal, etc.), beveiligde oorsprong (buitenste frame), en herschrijf oorsprong (binnenste frame). Elk heeft een andere behoefte:

  1. Portaal-oorsprong vereist datr.
  2. Veiligde oorsprong vereist ickt.
  3. Herschrijf-oorsprong vereist datr en ick.

Met localStorage protocol

Hier volgt een weergave van het bootstrap-proces voor de meeste moderne mobiele browsers:

Het is belangrijk op te merken dat om reflectie te voorkomen, het bootstrap-eindpunt bij de veilige oorsprong altijd een nieuwe ick en ickt uitgeeft; ick hangt nooit af van gebruikersinvoer. Merk op dat omdat we domain=.discoverapp.com op zowel ick als datr hebben ingesteld, ze beschikbaar zijn in alle origin types, en ickt alleen beschikbaar is op de beveiligde origin.

Zonder localStorage protocol

Omdat bepaalde browsers, zoals Opera Mini (populair in veel landen waar Discover actief is), localStorage niet ondersteunen, kunnen we de ick en ickt waarden niet opslaan. Dit betekent dat we een ander protocol moeten gebruiken:

We hebben besloten om de rewrite origin te scheiden van de secure origin, zodat ze niet hetzelfde host suffix delen volgens de Public Suffix List. We gebruiken www.0.discoverapp.com voor het opslaan van de beveiligde kopie van ickt (als een cookie), en verplaatsen alle oorsprong van derden onder 0.i.org. In een browser die zich goed gedraagt, zal het instellen van een cookie op de beveiligde oorsprong deze ontoegankelijk maken voor alle herschrijfbare oorsprongen.

Omdat de oorsprongen nu gescheiden zijn, wordt ons bootstrap proces een tweestapsproces. Voorheen konden we ick instellen in hetzelfde verzoek waarin we localStorage voorzien van ickt. Nu moeten we twee origins bootstrappen, in afzonderlijke verzoeken, zonder ick fixatievectoren te openen.

We lossen dit op door de beveiligde origin eerst te bootstrappen met het ickt cookie en de gebruiker een versleutelde versie van ick te geven, met een sleutel die alleen bekend is bij de proxy. De ick cijfertekst gaat vergezeld van een nonce die kan worden gebruikt om die specifieke ick in de herschrijf-oorsprong te ontcijferen en een cookie in te stellen, maar slechts eenmaal.

Een aanvaller zou kunnen kiezen om:

  1. De nonce te gebruiken om het ick cookie te onthullen.
  2. Het aan de gebruiker doorgeven om de waarde ervan vast te stellen.

In geen van beide gevallen kan de aanvaller tegelijkertijd een bepaalde ick waarde kennen en afdwingen bij een gebruiker. Het proces synchroniseert ook datr tussen de herkomsten.

Deze architectuur heeft aanzienlijke interne en externe veiligheidstests ondergaan. We geloven dat we een ontwerp hebben ontwikkeld dat robuust genoeg is om de soorten webapplicatie-aanvallen te weerstaan die we in het wild zien en veilig connectiviteit te leveren die duurzaam is voor mobiele operators. Na de lancering van Discover in Peru zijn we van plan om aanvullende Discover-proeven uit te rollen met partneroperators in een aantal andere landen waar we productfuncties in bèta hebben getest, waaronder Thailand, de Filippijnen en Irak. We verwachten dat Discover de komende weken in deze landen live zal gaan, en we zullen onderzoeken of we nog meer tests kunnen uitvoeren waaraan partneroperators willen deelnemen.

We willen Berk Demir bedanken voor zijn hulp bij dit werk.

In een poging om ons taalgebruik inclusiever te maken, hebben we in dit bericht “whitelist” vervangen door “allowlist.”

By: adminPosted on

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.