Yhteyspyrkimyksemme keskittyvät laajentamaan internetin käyttömahdollisuuksia ja käyttöönottoa kaikkialla maailmassa. Tähän sisältyy työmme Terragraphin kaltaisten teknologioiden parissa, yhteistyömme matkapuhelinoperaattoreiden kanssa maaseudun käyttömahdollisuuksien laajentamiseksi, työmme osana Telecom Infra Project -hanketta sekä Free Basicsin kaltaiset ohjelmat. Kun olemme jatkaneet Free Basics -ohjelman parissa työskentelyä, olemme kuunnelleet kansalaisyhteiskunnan ja muiden sidosryhmien palautetta ja suosituksia. Olemme kehittäneet Discoveria erityisesti näiden suositusten käsittelemiseksi ja sisällyttämiseksi uuteen tuotteeseen, joka tukee yhteyksiä. Tänään Facebook Connectivity ja kumppanimme Bitel, Claro, Entel ja Movistar aloittavat Discoverin kokeilun Perussa.

Tämän palvelun tarjoaminen ja samalla ihmisten suojaaminen mahdollisilta turvallisuusriskeiltä oli kova tekninen haaste. Halusimme kehittää mallin, jonka avulla voisimme turvallisesti esittää verkkosivuja kaikista saatavilla olevista verkkotunnuksista, mukaan lukien niiden resurssit (skriptit, media, tyylitiedostot jne.). Seuraavassa käymme läpi rakentamamme mallin, matkan varrella tekemämme ainutlaatuiset arkkitehtuurivalinnat ja toimenpiteet, joita olemme toteuttaneet riskien vähentämiseksi.

Missä aloitimme

Free Basics -palvelun osalta haasteemme oli löytää keino tarjota maksuton palvelu ihmisille, jotka käyttävät mobiiliverkkoa jopa ominaispuhelimilla, joilla ei ole kolmannen osapuolen sovellustukea. Matkapuhelinoperaattoreiden yhteistyökumppanit voisivat tarjota palvelun, mutta verkko- ja yhdyskäytävälaitteiden rajoitusten vuoksi vain tiettyihin kohteisiin (yleensä IP-osoitealueisiin tai luetteloon verkkotunnuksista) suuntautuva liikenne voitaisiin tehdä ilmaiseksi. Maailmanlaajuisesti oli yli 100 kumppania, ja operaattoreiden verkkolaitteiden kokoonpanojen muuttamiseen kului aikaa ja se oli vaikeaa, joten tajusimme, että meidän oli keksittävä uusi lähestymistapa.

Tämä uusi lähestymistapa edellytti, että rakensimme ensin verkkopohjaisen välityspalvelun, jossa operaattori voisi tarjota palvelun ilmaiseksi yhteen verkkotunnukseen: freebasics.com. Sieltä hakisimme verkkosivut käyttäjän puolesta ja toimittaisimme ne hänen laitteeseensa. Jopa nykyaikaisissa selaimissa verkkopohjaisiin välityspalvelinarkkitehtuureihin liittyy joitakin ongelmia. Verkossa asiakkaat voivat arvioida tietoturvaa koskevia HTTP-otsakkeita, kuten CORS (cross-origin resource sharing) ja CSP (Content Security Policy), ja käyttää evästeitä suoraan sivustolta. Välityspalvelinkokoonpanossa asiakas on vuorovaikutuksessa välityspalvelimen kanssa, ja välityspalvelin toimii sivuston asiakkaana. Kolmansien osapuolten sivustojen välittäminen yhden nimiavaruuden kautta rikkoo joitakin oletuksia, jotka koskevat evästeiden tallennustapaa, skriptien käyttöoikeuksia sisällön lukemiseen tai muokkaamiseen sekä CORS:n ja CSP:n arviointia.

Käsitellaksemme näitä huolenaiheita asetimme aluksi joitakin suoraviivaisia rajoituksia, muun muassa sen, millä sivustoilla voi vierailla Free Basicsin avulla, ja sen, ettei skriptejä voi ajaa. Jälkimmäisestä on ajan mittaan tullut suurempi ongelma, koska monet sivustot, myös mobiilisivustot, ovat alkaneet luottaa JavaScriptiin kriittisissä toiminnoissa, kuten sisällön renderöinnissä.

Varhainen arkkitehtuuri

Domain-suunnittelu

Sopeutuaksemme monien matkapuhelinoperaattoreiden yhdyskäytävien rajoitettuun toimintakykyyn harkitsimme vaihtoehtoisia arkkitehtuureja, mukaan lukien:

  1. Yhteistoiminnallista ratkaisua, jossa verkkosivut voivat varata alatunnuksen (esim, free.example.com) ja ratkaista sen meidän IP-avaruuteemme, jotta operaattorit voivat tehdä sen maksutta käyttäjälle.

Tässä ratkaisussa oli hyviä puolia:

  • Se mahdollisti suoran päästä päähän -viestinnän asiakkaan ja palvelimen välillä.
  • Se vaati minimaalisen vähän toimenpiteitä välityspalvelimen puolella.

Tässä oli kuitenkin myös joitakin haittoja:

  • Sivustojen oli valittava tämä järjestelmä, mikä aiheutti ylimääräisiä suunnittelukustannuksia sivustojen omistajille.
  • Selainten oli pyydettävä tiettyä verkkotunnusta SNI:n (Server Name Indication) kautta, jotta välityspalvelin tietäisi, mihin muodostaa yhteyden. SNI-tuki ei kuitenkaan ole yleistä, mikä teki tästä ratkaisusta vähemmän käyttökelpoisen.
  • Jos tilaajat selaisivat vahingossa suoraan osoitteeseen example.com eikä aliverkkoon free.example.com, heille aiheutuisi maksuja – eikä heitä välttämättä ohjattaisi aliverkkoon, ellei operaattori olisi ottanut käyttöön jotain ylimääräistä logiikkaa.
  1. IPv4-in-IPv6-kapselointi, jossa koko IPv4-avaruus voidaan kapseloida yhden vapaan datan IPv6-aliverkon sisään. Räätälöity DNS-resolveri ratkaisee tällöin IPv4:n rekursiivisesti ja vastaa kapseloidulla IPv6-vastauksella.

Tässä ratkaisussa oli myös hyviä puolia:

  • Se ei vaatinut verkkosivujen omistajalta yhteistyötä.
  • Edellisen IP:n ratkaisemiseen ei tarvittu SNI:tä.

Ja haittoja:

  • Selaimet näkivät www.example.com.freebasics.com-verkkotunnuksen, mutta www.example.com-varmenne johti virheeseen.
  • Vain harvat operaattorien yhdyskäytävät tukivat IPv6:aa tällä tavalla.
  • Vielä harvemmat laitteet tukivat IPv6:aa, etenkin vanhemmat käyttöjärjestelmäversiot.

Kumpikaan näistä ei ollut toimiva ratkaisu. Lopulta päätimme, että paras mahdollinen arkkitehtuuri olisi origin collapsing, jossa välityspalvelimemme toimii yhden origin collapsed domain -nimiavaruuden sisällä osoitteessa freebasics.com. Näin operaattorit voivat helpommin sallia liikenteen tähän kohteeseen ja pitää määritykset yksinkertaisina. Jokainen kolmannen osapuolen alkuperä on koodattu aliverkkotunnukseen, joten voimme taata, että nimien resoluutio ohjaa liikenteen aina vapaaseen IP-osoitteeseen.

Esimerkiksi:

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

Kirjoitetaan uudelleen muotoon:

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

Käytössä on kattava palvelinlogiikka, jolla varmistetaan, että linkit ja hrefs-tiedot muunnetaan oikein. Tämä sama logiikka auttaa varmistamaan, että jopa vain HTTP-sivut toimitetaan turvallisesti HTTPS:n kautta Free Basicsissa asiakkaan ja välityspalvelimen välillä. Tämän URL-osoitteiden uudelleenkirjoitusjärjestelmän ansiosta voimme käyttää yhtä ainoaa nimiavaruutta ja TLS-varmentetta sen sijaan, että tarvitsisimme erillisen varmenteen jokaiselle internetin aladomainille.

Kaikki internetin alkuperät muuttuvat sisaruksiksi 0.freebasics.com:n alle, mikä herättää tiettyjä turvallisuusnäkökohtia. Emme voineet hyödyntää verkkotunnuksen lisäämistä Public Suffix List -luetteloon, koska meidän olisi pitänyt antaa eri eväste jokaiselle alkuperälle, mikä lopulta ylittäisi selaimen evästeiden rajoitukset.

Evästeet

Toisin kuin verkko-asiakkaat, jotka voivat hyödyntää evästeitä suoraan sivustolta, välityspalvelu vaatii erilaisen asennuksen. Free Basics tallentaa käyttäjän evästeet palvelimen puolelle useista syistä:

  1. Alemman tason mobiiliselaimissa on usein rajoitettu evästetuki. Jos annamme edes yhden evästeen jokaista sivustoa kohden välityspalvelinverkkotunnuksessamme, voimme tyytyä asettamaan vain kymmeniä evästeitä. Jos Free Basics asettaisi asiakaspuolen evästeet jokaiselle 0.freebasics.com:n alla olevalle sivustolle, vanhemmat selaimet saavuttaisivat nopeasti evästeiden paikallisen tallennusrajoituksen – ja jopa nykyaikaiset selaimet saavuttaisivat verkkotunnuskohtaisen rajoituksen.
  2. Toteuttamamme verkkotunnuksen nimiavaruusrajoitukset estivät myös sisar- ja hierarkkisten evästeiden käytön. Esimerkiksi missä tahansa aliverkkotunnuksessa .example.com asetettu eväste olisi normaalisti luettavissa missä tahansa muussa aliverkkotunnuksessa. Toisin sanoen, jos a.example.com asettaa evästeen .example.com:lle, b.example.com:n pitäisi pystyä lukemaan se. Free Basicsin tapauksessa a-example-com.0.freebasics.com asettaisi evästeen osoitteeseen example.com.0.freebasics.com, mikä ei ole standardin mukaan sallittua. Koska tämä ei toimi, muut alkuperät, kuten b-example-com.0.freebasics.com, eivät pystyisi käyttämään emoalueen evästeitä.

Jotta välityspalvelu pääsisi käsiksi tähän palvelinpuolen evästeiden purkkiin, Free Basics käyttää kahta asiakaspuolen evästettä:

  1. datr-eväste, selaimen tunniste, jota käytetään sivuston eheyteen.
  2. ick (internet evästeen avain), joka sisältää salausavaimen, jota käytetään palvelinpuolen evästeiden salaamiseen. Koska tämä avain säilytetään vain asiakaspuolella, Free Basics ei voi purkaa palvelinpuolen evästepurkin salausta silloin, kun käyttäjä ei käytä palvelua.

Käyttäjien yksityisyyden ja turvallisuuden suojaamiseksi, kun evästeet tallennetaan palvelinpuolen evästepurkkiin, varmistamme, että:

  1. Palvelinpuolen evästeet salataan ick:lla, jota säilytetään vain asiakkaalla.
  2. Kun asiakas antaa ick:n, palvelin unohtaa sen jokaisessa pyynnössä ilman, että sitä koskaan kirjataan.
  3. Merkitsemme molemmat asiakaspuolen evästeet Secure:ksi ja HttpOnly:ksi.
  4. Hashaamme evästeen indeksin asiakaspuolen avaimen avulla, jotta eväste ei ole jäljitettävissä takaisin käyttäjään, kun avainta ei ole.

Skriptien salliminen vaarantaa palvelinpuolen evästeiden kiinnittymisen. Tämän estämiseksi suljemme JavaScriptin käytön pois Free Basicsista. Lisäksi, vaikka mikä tahansa verkkosivusto voi olla osa Free Basics -palvelua, tarkastamme jokaisen sivuston erikseen mahdollisten väärinkäytöksien varalta sisällöstä riippumatta.

Rakentamamme parantaminen

Tukeaksemme mallia, joka palvelee mitä tahansa verkkosivustoa ja jossa skriptien suorittaminen on entistä turvallisempaa, meidän oli ajateltava arkkitehtuuriamme merkittävästi uudelleen estääkseen uhkatekijät, joita ovat esimerkiksi skriptit, jotka pystyvät lukemaan tai fiksaamaan käyttäjän evästeitä. JavaScriptiä on erittäin vaikea analysoida ja estää tahattoman koodin suorittaminen.

Tässä on esimerkkinä joitakin tapoja, joilla hyökkääjä voisi syöttää koodia, joka meidän pitäisi pystyä suodattamaan:

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

Keksimämme malli laajensi Free Basics -mallia, mutta se suojaa myös salausavaimen tallentavan evästeen siltä, että skriptit eivät voisi korvata sitä. Käytämme ulkoista kehystä, johon luotamme todistaaksemme, että sisäistä kehystä, joka esittää kolmannen osapuolen sisältöä, ei ole peukaloitu. Seuraavassa osiossa esitellään yksityiskohtaisesti, miten lievennämme istunnon kiinnittymistä ja muita hyökkäyksiä, kuten phishingiä ja clickjackingia. Esittelemme menetelmän, jolla voidaan turvallisesti tarjota kolmannen osapuolen sisältöä ja samalla mahdollistaa JavaScriptin suoritus.

Arkkitehtuurin parannukset Discoverissa

Viittaukset verkkotunnukseen muuttuvat tässä vaiheessa uudeksi verkkotunnukseksemme, joka on vastaavalla tavalla alkuperältään supistettu discoverapp.com.

JavaScript ja evästeiden kiinnittäminen

Salliessamme JavaScriptin kolmansien osapuolten sivustoilla meidän on täytynyt tunnustaa, että tämä mahdollistaa tietyt vektorit, joihin meidän on pitänyt varautua, sillä skriptit voivat muokata ja uudelleenkirjoittaa linkkejä, päästä käsiksi mihin tahansa DOM:n osaan ja pahimmassa tapauksessa kiinnittää asiakaspuolen evästeitä.

Keksimässämme ratkaisussa oli puututtava evästeiden kiinnittämiseen, joten sen sijaan, että yrittäisimme analysoida ja estää tietyt komentosarjakutsut, päätimme havaita sen heti, kun se tapahtuu, ja tehdä sen hyödyttömäksi. Tämä saavutetaan seuraavalla tavalla:

  1. Liittymisen yhteydessä luomme uuden, suojatun satunnaisen ick:n.
  2. Lähetämme ick:n selaimelle HttpOnly-evästeenä.
  3. Tämän jälkeen HMAC-arvo nimeltä ickt muodostetaan sekä ick:n että datr:n digestistä (molempien fiksaation välttämiseksi) ja tallennamme kopion ickt:stä asiakkaalle localStorage:n paikkaan, johon mahdollinen hyökkääjä ei voi kirjoittaa. Käyttämämme sijainti on https://www.0.discoverapp.com, joka ei koskaan palvele kolmannen osapuolen sisältöä. Koska tämä alkuperä on kaikkien kolmansien osapuolten alkuperien sisar, verkkotunnuksen alentamista tai muuta verkkotunnuksen muuttamista ei voi tapahtua, ja alkuperää pidetään luotettavana.
  4. Upotamme ickt, joka on peräisin pyynnössä näkyvästä ick-evästeestä, HTML:n sisälle jokaisessa kolmannen osapuolen välityspalvelimen vastauksessa.
  5. Sivun latautuessa vertaamme upotettua ickt:ää luotettuun ickt:ään window.postMessage():n avulla ja mitätöimme istunnon, jos se ei vastaa toisiaan, poistamalla datr– ja ick-evästeet.
  6. Estämme käyttäjän vuorovaikutuksen sivun kanssa, kunnes tämä prosessi on päättynyt.

Lisäsuojana asetamme uuden datr-evästeen, jos havaitsemme useita evästeitä samassa paikassa, ja upotamme siihen aikaleiman, jotta voimme aina käyttää viimeisintä.

Kahden kehyksen ratkaisu

Validoinnissa tarvitsemme tavan, jonka avulla kolmas osapuoli voi sivultaan tiedustella ickt:n arvoa ja validoida sen. Teemme tämän upottamalla kolmannen osapuolen sivuston <iframe>:n sisään suojatun alkuperän sivulla ja injektoimalla JavaScript-pätkän kolmannen osapuolen sivustoon. Rakennamme turvallisen ulomman kehyksen ja kolmannen osapuolen sisäisen kehyksen.

Sisäinen kehys

Sisäisen kehyksen sisällä injektoimme skriptin jokaiseen tarjoamaamme välityssivuun. Ruiskutamme sen mukana myös ickt-arvon, joka on laskettu pyynnössä nähdystä ick-arvosta. Sisäisen kehyksen käyttäytyminen on seuraava:

  1. Tarkista ulomman kehyksen kanssa:
    • postMessage alkuun sivulle upotetulla ickt:llä.
    • Odota.
  2. Jos skripti saa kuittauksen suojatulta alkuperältään, annamme käyttäjän olla vuorovaikutuksessa sivun kanssa.
  3. Jos skripti odottaa liian kauan tai saa vastauksen odottamattomasta alkuperästä, navigoimme kehyksen virheruutuun, jossa ei ole kolmannen osapuolen sisältöä (meidän ”Hups” -sivumme), koska on mahdollista, että ulompi kehys ei ole siellä tai se on erilainen kuin sisäinen kehys odottaa.
  4. Tarkista parent:llä:
    • postMessage osoitteeseen parent.
    • Odota.
    • Jos komentosarja saa vastauksen, jossa on merkintä source===parent ja alkuperä on .0.discoverapp.com:n alla, se jatkaa eteenpäin.
    • Jos komentosarja odottaa liian kauan tai saa vastauksen odottamattomalta alkuperältään, navigoimme ”Hups” -sivulle.

Joitakin huomioita sisäkehyksestä:

  1. Sitäkin huolimatta, että se kierretään, potentiaaliset hyökkääjät pystyisivät kiinnittymään vain alkuperään, jolla he voivat saavuttaa koodin suorituksen, jolloin evästeiden kiinnittymisvektorit olisivat turhia.
  2. Emme oleta, että hyvänlaatuinen alkuperä ei tahallaan kierrä sisä-ulkoinen-viestiprotokollaa.

ulkokehys

Ulkoinen kehys on olemassa todistaaksemme, että sisäinen kehys on johdonmukainen:

  1. Varmennamme, että ulkoinen kehys on aina ylin kehys JavaScriptillä ja X-Frame-Options: DENY.
  2. Odotetaan postMessage.
  3. Jos ulompi kehys vastaanottaa viestin:
    • Onko se peräisin sisemmän kehyksen alkuperästä?
    • Jos kyllä, ilmoittaako se oikean ickt-arvon?
      • Jos kyllä, lähetetään kuittausviesti.
      • Jos ei, poistetaan istunto, poistetaan kaikki evästeet ja siirrytään turvalliseen alkuperään.
  4. Jos ulkokehys ei saa viestiä muutamaan sekuntiin tai alakehys ei ole ylin sisäkehys, poistamme sijainnin turvallisen kehyksen osoitepalkista.

Sivun vuorovaikutus

Välttääksemme kilpajuoksutilanteet, joissa henkilö saattaisi syöttää salasanan fiksoidun evästeen alle ennen kuin sisempi kehys on saanut varmistuksen valmiiksi, on tärkeää estää henkilöitä toimimasta vuorovaikutuksessa sivun kanssa ennen kuin sisemmän kehyksen varmistussekvenssi on saatu valmiiksi.

Tämä estetään lisäämällä palvelimella style="display:none" jokaiseen <html>-elementtiin <html>. Sisempi kehys poistaa sen, kun se saa ulomman kehyksen vahvistuksen.

JavaScript-koodin suorittaminen sallitaan edelleen, ja resursseja haetaan edelleen. Mutta niin kauan kuin henkilö ei ole syöttänyt mitään syötettä sivulle, selain ei tee mitään, mitä mahdollinen hyökkääjä ei olisi voinut tehdä käymällä sivustolla – paitsi jos sivusto on jo haavoittuvainen ristikkäisten pyyntöjen väärentämiselle (cross-site request forgery, CSRF).

Valinnutessamme tämän ratkaisun meidän oli ratkaistava muita mahdollisia lopputuloksia, tarkemmin sanottuna:

  1. Asynkroninen evästeiden kiinnitys.
  2. Clickjacking framingin vuoksi.
  3. Phishing, joka esiintyy Discover-verkkotunnuksena.

Asynkroninen evästeiden kiinnittyminen

Tähän asti toteuttamamme suojaukset ovat ottaneet huomioon synkroniset kiinnittymiset, mutta niitä voi tapahtua myös asynkronisesti. Tämän estämiseksi käytämme klassista CSRF-torjuntamenetelmää. Edellytämme, että POST-lähetyksissä on kyselyparametri, jossa on datr, joka on nähty sivun latautuessa. Sitten vertaamme kyselyparametria pyynnössä nähtyyn datr-evästeeseen. Jos ne eivät täsmää, emme täytä pyyntöä.

datr-vuodon välttämiseksi upotamme datr:n salatun version sisäkehyksen sisälle ja varmistamme, että tämä kyselyparametri lisätään jokaiseen <form>– ja XHR-objektiin. Koska sivu ei voi itse johtaa datr-tunnusta, lisätty datr on se datr, joka nähdään sillä hetkellä.

Anonyymien pyyntöjen osalta edellytämme, että myös niissä on datr-kyselyparametri. Anonymiteetti säilyy, koska emme vuoda sitä kolmannen osapuolen sivustolle – ick-eväste puuttuu, joten emme voi käyttää evästepurkkia. Tässä tapauksessa emme kuitenkaan pysty validoimaan datr-evästeen perusteella, joten anonyymejä POSTeja voidaan tehdä kiinnitetyissä istunnoissa. Mutta koska ne ovat anonyymejä ja niistä puuttuu ick, mitään arkaluonteisia tietoja ei voi vuotaa.

Clickjacking

Kun sivusto lähettää X-Frame-Options: DENY, se ei lataudu sisäkehykseen. Sivustot käyttävät tätä otsikkoa estääkseen altistumisen tietyntyyppisille hyökkäyksille, kuten clickjackingille. Poistamme kyseisen otsikon HTTP-vastauksesta, mutta pyydämme sisäistä kehystä varmistamaan, että parent on top-ikkunakehys käyttäen postMessage. Jos vahvistus epäonnistuu, ohjaamme käyttäjän ”Hups”-sivulle.

Phishing

Suojatussa kehyksessä tarjoamaamme ”osoitepalkkia” käytetään paljastamaan ylimmän sisäkehyksen alkuperä käyttäjälle. Sen voivat kuitenkin kopioida Phishing-sivustot, jotka esiintyvät Discoverina. Estämme haitallisten linkkien navigoinnin pois Discoverista estämällä yläreunan navigoinnin käyttämällä <iframe sandbox>. Ulomman kehyksen voi paeta vain navigoimalla suoraan toiselle sivustolle.

Client-side cookies

document.cookie sallii JavaScriptin lukea ja muokata evästeitä, joita ei ole merkitty HttpOnly. Tämän tukeminen turvallisesti on haastavaa järjestelmässä, joka säilyttää evästeet palvelimella.

Västeiden käyttäminen: Kun pyyntö vastaanotetaan, välityspalvelin luettelee kaikki evästeet, jotka ovat näkyvissä kyseiselle alkuperälle. Sen jälkeen se liittää JSON-hyötykuorman vastaussivulle. Asiakaspuolen koodi injektoidaan shim document.cookie ja tekee näistä evästeistä näkyviä muille skripteille, ikään kuin ne olisivat oikeita asiakaspuolen evästeitä.

Västeiden muokkaaminen:

Luottamus selaimen CORS-ominaisuuksiin ei riittäisi tässä tapauksessa – selain estää origon a.example.com, joka yrittää asettaa evästeen example.com:lle, koska nämä origot ovat sisaruksia eivätkä hierarkkisia.

Siltikin, kun palvelin vastaanottaa asiakkaan asettaman uuden evästeen, se ei voi turvallisesti valvoa, onko kohdealue sallittu; kirjoittajan alkuperä on tiedossa vain asiakkaalla, eikä sitä aina lähetetä palvelimelle luotettavalla tavalla.

Pakottaakseen asiakkaan todistamaan, että se on oikeutettu asettamaan evästeitä tietylle verkkotunnukselle, palvelin lähettää JSON-hyötykuorman lisäksi luettelon kryptografisista tunnisteista jokaisesta alkuperästä (origins), jossa pyytävällä alkuperällä on lupa asettaa evästeitä. Nämä tunnisteet suolataan ick-arvolla, joten niitä ei voida siirtää käyttäjien välillä.

document.cookie:n asiakaspuolen shim huolehtii tunnisteen resoluutiosta ja upottamisesta varsinaiseen evästetekstiin, joka lähetetään välittäjälle. Jokaisella on eri tarve:

  1. Portal origin vaatii datr.
  2. Secure origin vaatii ickt.
  3. Rewrite origin vaatii datr ja ick.

With localStorage protocol

Tässä on esitys bootstrap-prosessista useimmille nykyaikaisille mobiiliselaimille:

On tärkeää huomata, että heijastuksen välttämiseksi bootstrap-päätepiste turvallisessa alkuperässä antaa aina uuden ick:n ja ickt:n; ick ei koskaan ole riippuvainen käyttäjän syötteestä. Huomaa, että koska asetamme domain=.discoverapp.com sekä ick:lle että datr:lle, ne ovat käytettävissä kaikissa alkuperätyypeissä, ja ickt on käytettävissä vain suojatussa alkuperässä.

Ei localStorage-protokollaa

Koska tietyt selaimet, kuten Opera Mini (suosittu monissa maissa, joissa Discover toimii), eivät tue localStorage:aa, emme pysty tallentamaan arvoja ick ja ickt. Tämä tarkoittaa, että meidän on käytettävä eri protokollaa:

Päätimme erottaa uudelleenkirjoitusalkuperän ja suojatun alkuperän toisistaan, jotta niillä ei ole samaa isäntäsuffiksia julkisen Suffix-luettelon mukaisesti. Käytämme www.0.discoverapp.com:tä suojatun kopion ickt tallentamiseen (evästeenä) ja siirrämme kaikki kolmannen osapuolen alkuperät 0.i.org:n alle. Hyvin käyttäytyvässä selaimessa evästeen asettaminen suojattuun alkuperään tekee siitä saavuttamattoman kaikille uudelleenkirjoittaville alkuperille.

Koska alkuperät ovat nyt erillään, käynnistysprosessistamme tulee kaksivaiheinen prosessi. Ennen pystyimme asettamaan ick samassa pyynnössä, jossa määrittelemme localStorage ja ickt. Nyt meidän on käynnistettävä kaksi alkuperää erillisissä pyynnöissä avaamatta ick:n kiinnitysvektoreita.

Ratkaisemme tämän käynnistämällä suojatun alkuperän ensin ickt-evästeellä ja antamalla käyttäjälle salatun version ick:stä, jonka avaimen tuntee vain välittäjä. ick-salaustekstin mukana on nonce, jota voidaan käyttää kyseisen ick:n salauksen purkamiseen uudelleenkirjoitetussa alkuperässä ja evästeen asettamiseen, mutta vain kerran.

Hyökkääjä voi valita joko:

  1. Käyttää noncea ick-evästeen paljastamiseen.
  2. antaa sen käyttäjälle sen arvon kiinnittämiseksi.

Kummassakaan tapauksessa hyökkääjä ei voi samanaikaisesti tietää ja pakottaa käyttäjälle tiettyä ick-arvoa. Prosessi myös synkronoi datr alkuperien välillä.

Tämä arkkitehtuuri on käynyt läpi huomattavan sisäisen ja ulkoisen tietoturvatestauksen. Uskomme, että olemme kehittäneet rakenteen, joka on riittävän vankka vastustamaan luonnossa esiintyviä verkkosovellushyökkäyksiä ja tarjoamaan turvallisesti matkapuhelinoperaattoreille kestävän yhteyden. Discoverin lanseerauksen jälkeen Perussa suunnittelemme Discoverin lisäkokeiluja kumppanioperaattoreiden kanssa useissa muissa maissa, kuten Thaimaassa, Filippiineillä ja Irakissa, joissa olemme beta-testanneet tuoteominaisuuksia. Odotamme, että Discover otetaan käyttöön näissä maissa lähiviikkoina, ja tutkimme muita kokeiluja, joihin kumppanioperaattorit haluavat osallistua.

Kiitämme Berk Demiriä hänen avustaan tässä työssä.

Pyrkiessämme käyttämään kattavampaa kieltä olemme muokanneet tätä viestiä korvataksemme sanan ”whitelist” sanalla ”allowlist”.

By: adminPosted on

Vastaa

Sähköpostiosoitettasi ei julkaista.