Eforturile noastre de conectivitate se concentrează pe extinderea accesului la internet și adoptarea acestuia în întreaga lume. Aceasta include activitatea noastră privind tehnologii precum Terragraph, colaborarea noastră cu operatorii de telefonie mobilă privind eforturile de extindere a accesului în mediul rural, activitatea noastră ca parte a Telecom Infra Project și programe precum Free Basics. Pe măsură ce am continuat să lucrăm la Free Basics, am ascultat feedback-ul și recomandările din partea societății civile și a altor părți interesate. Am dezvoltat Discover special pentru a aborda și încorpora aceste recomandări într-un nou produs care sprijină conectivitatea. Astăzi, Facebook Connectivity și partenerii noștri de la Bitel, Claro, Entel și Movistar lansează un test al Discover în Peru.

Furnizarea acestui serviciu, menținând în același timp oamenii în siguranță față de potențialele riscuri de securitate, a fost o provocare tehnică dificilă. Am vrut să dezvoltăm un model care să ne permită să prezentăm în siguranță paginile web din toate domeniile disponibile, inclusiv resursele acestora (scripturi, media, foi de stil etc.). Mai jos, trecem în revistă modelul pe care l-am construit, alegerile unice de arhitectură pe care le-am făcut pe parcurs și măsurile pe care le-am luat pentru a reduce riscurile.

De unde am pornit

Pentru Free Basics, provocarea noastră a fost să găsim o modalitate de a oferi un serviciu fără costuri persoanelor care utilizează web-ul mobil, chiar și pe telefoane cu funcții fără suport pentru aplicații de la terți. Partenerii operatorilor de telefonie mobilă puteau furniza serviciul, dar constrângerile legate de rețea și de echipamentele de gateway făceau ca doar traficul către anumite destinații (de obicei, intervale de adrese IP sau o listă de nume de domenii) să poată fi făcut gratuit. Cu peste 100 de parteneri la nivel global și cu timpul și dificultatea pe care le implică schimbarea configurațiilor echipamentelor de rețea ale operatorilor de telefonie mobilă, ne-am dat seama că trebuie să găsim o nouă abordare.

Această nouă abordare ne-a impus să construim mai întâi un serviciu proxy bazat pe web prin care operatorul să poată pune la dispoziție serviciul gratuit pentru un singur domeniu: freebasics.com. De acolo, noi am fi preluat pagini web în numele utilizatorului și le-am fi livrat pe dispozitivul acestuia. Chiar și în cazul browserelor moderne, există unele probleme legate de arhitecturile proxy bazate pe web. Pe web, clienții sunt capabili să evalueze antetele HTTP de securitate, cum ar fi cross-origin resource sharing (CORS) și Content Security Policy (CSP) și să utilizeze cookie-uri direct de pe site. Însă, într-o configurație de server proxy, clientul interacționează cu proxy-ul, iar acesta din urmă acționează ca un client al site-ului. Proxarea site-urilor web ale terților prin intermediul unui singur spațiu de nume încalcă anumite ipoteze legate de modul în care sunt stocate cookie-urile, cât de mult acces au scripturile pentru a citi sau edita conținutul și cum sunt evaluate CORS și CSP.

Pentru a răspunde acestor preocupări, am impus inițial câteva limitări simple, inclusiv ce site-uri pot fi vizitate cu Free Basics și imposibilitatea de a rula scripturi. Aceasta din urmă a devenit mai mult o problemă în timp, deoarece multe site-uri web, inclusiv site-urile mobile, au început să se bazeze pe JavaScript pentru funcționalități critice, inclusiv pentru redarea conținutului.

Arhitectura inițială

Proiectarea domeniului

Pentru a ține cont de funcționalitatea limitată a multor gateway-uri ale operatorilor de telefonie mobilă, am luat în considerare arhitecturi alternative, inclusiv:

  1. O soluție de cooperare în care site-urile web pot aloca un subdomeniu (de ex, free.example.com) și îl rezolvă în spațiul nostru IP pentru ca operatorii să îl pună gratuit la dispoziția utilizatorului.

Această soluție a avut avantaje:

  • A permis o comunicare directă de la un capăt la altul între client și server.
  • A necesitat o intervenție minimă din partea proxy-ului.

Cu toate acestea, avea și unele dezavantaje:

  • Site-urile trebuiau să opteze pentru această schemă, ceea ce presupunea costuri suplimentare de inginerie pentru proprietarii de site-uri.
  • Browserele trebuiau să solicite un domeniu specific prin Indicarea numelui serverului (SNI), astfel încât proxy-ul să știe unde să se conecteze. Cu toate acestea, suportul pentru SNI nu este universal, ceea ce a făcut ca această soluție să fie mai puțin viabilă.
  • Dacă abonații navigau din greșeală direct la example.com, în loc să navigheze la subdomeniul free.example.com, aceștia ar suporta taxe – și nu ar fi fost neapărat redirecționați către subdomeniu, cu excepția cazului în care operatorul ar fi implementat o logică suplimentară.
  1. Încapsularea IPv4 în IPv6, în care putem încapsula întregul spațiu IPv4 într-o singură subrețea IPv6 de date libere. Un rezolvator DNS personalizat rezolvă apoi IPv4 în mod recursiv și răspunde cu răspunsuri IPv6 încapsulate.

Această soluție a avut și avantaje:

  • Nu a necesitat cooperare din partea proprietarului site-ului web.
  • Nu a fost nevoie de SNI pentru a rezolva IP-ul la distanță.

Și contra:

  • Browserele ar fi văzut domeniul www.example.com.freebasics.com, dar certificatul www.example.com ar fi produs o eroare.
  • Doar câteva gateway-uri ale operatorilor suportau IPv6 în acest mod.
  • Cei mai puțini dispozitive suportau IPv6, în special versiunile mai vechi ale sistemului de operare.

Niciuna dintre acestea nu era o soluție viabilă. În cele din urmă, am decis că cea mai bună arhitectură posibilă ar fi colapsarea originii, în care proxy-ul nostru rulează în cadrul unui singur spațiu de nume de domeniu colapsat de origine sub freebasics.com. Operatorii pot apoi să aloce mai ușor traficul de tip „allowlist” către această destinație și să își păstreze configurațiile simple. Fiecare origine terță parte este codificată într-un subdomeniu, astfel încât putem garanta că rezoluția numelui va direcționa întotdeauna traficul către un IP liber.

De exemplu:

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

Este rescrisă în:

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

Există o logică extinsă de partea serverului pentru a se asigura că legăturile și hrefs sunt transformate corect. Aceeași logică ajută la asigurarea faptului că și site-urile exclusiv HTTP sunt livrate în siguranță prin HTTPS pe Free Basics între client și proxy. Această schemă de rescriere a URL-urilor ne permite să folosim un singur spațiu de nume și un singur certificat TLS, în loc să solicităm un certificat separat pentru fiecare subdomeniu de pe internet.

Toate originile de pe internet devin frați sub 0.freebasics.com, ceea ce ridică anumite considerente de securitate. Nu am putut profita de adăugarea domeniului la lista de sufixe publice, deoarece ar fi trebuit să emitem un cookie diferit pentru fiecare origine, ceea ce ar fi depășit în cele din urmă limitele cookie-urilor din browser.

Cookies

În comparație cu clienții web, care pot utiliza cookie-urile direct de pe site, serviciul proxy necesită o configurație diferită. Free Basics stochează cookie-urile utilizatorilor pe partea serverului din mai multe motive:

  1. Furnizoarele mobile de nivel inferior au adesea un suport limitat pentru cookie-uri. Dacă emitem chiar și un singur cookie pentru fiecare site sub domeniul nostru proxy, am putea fi limitați la setarea a doar câteva zeci de cookie-uri. Dacă Free Basics ar trebui să seteze cookie-uri pe client pentru fiecare site de sub 0.freebasics.com, browserele mai vechi ar atinge rapid limitele de stocare locală a cookie-urilor – și chiar și browserele moderne ar atinge o limită per domeniu.
  2. Constrângerile de spațiu de nume de domeniu pe care trebuia să le implementăm au împiedicat, de asemenea, utilizarea cookie-urilor frate și ierarhice. De exemplu, un modul cookie setat pe orice subdomeniu la .example.com ar fi în mod normal lizibil la orice alt subdomeniu. Cu alte cuvinte, dacă a.example.com setează un modul cookie pe .example.com, atunci b.example.com ar trebui să fie capabil să îl citească. În cazul Free Basics, a-example-com.0.freebasics.com ar seta un cookie pe example.com.0.freebasics.com, ceea ce nu este permis conform standardului. Din moment ce acest lucru nu funcționează, alte origini, cum ar fi b-example-com.0.freebasics.com, nu ar putea accesa cookie-urile setate pentru domeniul lor părinte.

Pentru a permite serviciului proxy să acceseze acest borcan de cookie-uri de pe server, Free Basics utilizează două cookie-uri de pe client:

  1. Cookie-ul datr, un identificator al browserului utilizat în scopul integrității site-ului.
  2. The ick (internet cookie key), care conține o cheie criptografică utilizată pentru a cripta borcanul de cookie-uri de pe partea serverului. Deoarece această cheie este stocată numai pe partea clientului, borcanul de cookie-uri de pe server nu poate fi decriptat de Free Basics atunci când utilizatorul nu utilizează serviciul.

Pentru a ajuta la protejarea confidențialității și securității utilizatorilor atunci când își stochează cookie-urile într-un borcan de cookie-uri de pe server, ne asigurăm că:

  1. Copiile cookie de pe server sunt criptate cu un ick care este păstrat numai pe client.
  2. Când clientul furnizează ick, acesta este uitat de server la fiecare cerere, fără a fi înregistrat vreodată.
  3. Marcăm ambele cookie-uri de pe partea clientului ca fiind Secure și HttpOnly.
  4. Hashăm indexul unui cookie folosind cheia de pe partea clientului, astfel încât cookie-ul să nu poată fi urmărit până la utilizator atunci când cheia nu este prezentă.

Permițând scripturilor să ruleze riscăm fixarea cookie-urilor de pe partea serverului. Pentru a preveni acest lucru, excludem utilizarea JavaScript din Free Basics. În plus, chiar dacă orice site web poate face parte din Free Basics, analizăm fiecare site în mod individual pentru potențiali vectori de abuz, indiferent de conținut.

Îmbunătățirea a ceea ce am construit

Pentru a susține un model care deservește orice site web, cu posibilitatea de a rula scripturi în condiții de mai mare siguranță, a trebuit să ne regândim în mod semnificativ arhitectura pentru a preveni amenințările, cum ar fi faptul că scripturile pot fie să citească, fie să fixeze modulele cookie ale utilizatorului. JavaScript este extrem de dificil de analizat și de împiedicat executarea unui cod neintenționat.

Ca exemplu, iată câteva moduri în care un atacator ar putea injecta cod pe care ar trebui să fim capabili să îl filtrăm:

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

Modelul la care am ajuns a extins designul Free Basics, dar protejează și cookie-ul care stochează cheia de criptare de a fi suprascris de scripturi. Folosim un cadru exterior în care avem încredere pentru a atesta că cadrul interior, care prezintă conținutul terților, nu este manipulat. Următoarea secțiune prezintă în detaliu modul în care atenuăm fixarea sesiunii și alte atacuri, cum ar fi phishing-ul și clickjacking-ul. Prezentăm o metodă pentru a servi în siguranță conținut de la terți, permițând în același timp executarea JavaScript.

Ambunătățiri de arhitectură în Discover

Referințele la domeniu în acest moment se vor schimba în noul nostru domeniu, un discoverapp.com cu origine similară.

JavaScript și fixarea cookie-urilor

În permițând JavaScript de pe site-urile terților, a trebuit să recunoaștem că acest lucru permite anumiți vectori pentru care trebuia să ne pregătim, deoarece scripturile pot modifica și rescrie link-urile, pot accesa orice parte a DOM și, în cel mai rău caz, pot fixa cookie-urile de pe partea clientului.

Soluția pe care am găsit-o trebuia să abordeze fixarea cookie-urilor, așa că, în loc să încercăm să analizăm și să blocăm anumite apeluri de script, am decis să le detectăm în momentul în care se întâmplă și să le facem inutile. Acest lucru este realizat prin următoarele:

  1. La înscriere, generăm un nou ick aleatoriu și sigur.
  2. Întocmai trimitem ick la browser ca un cookie HttpOnly.
  3. Noi apoi HMAC o valoare numită ickt dintr-o digestă atât a lui ick cât și a lui datr (pentru a evita fixarea pentru ambele) și stocăm o copie a lui ickt pe client, într-o locație din localStorage în care un potențial atacator nu poate scrie. Locația pe care o folosim este https://www.0.discoverapp.com, care nu servește niciodată conținut terț. Având în vedere că această origine este frate cu toate originile terților, nu se poate produce scăderea domeniului sau orice alt tip de modificare a domeniului, iar originea este considerată de încredere.
  4. Încorporăm ickt, derivat din cookie-ul ick văzut în cerere, în interiorul codului HTML din fiecare răspuns proxy terț.
  5. Când se încarcă pagina, comparăm ickt încorporat cu ickt de încredere folosind window.postMessage() și invalidăm sesiunea dacă există o neconcordanță prin ștergerea cookie-urilor datr și ick.
  6. Împiedicăm interacțiunea utilizatorului cu pagina până la finalizarea acestui proces.

Ca protecție suplimentară, setăm un nou cookie datr dacă detectăm mai multe cookie-uri în aceeași locație, încorporând un marcaj de timp astfel încât să îl putem folosi întotdeauna pe cel mai recent.

Soluția cu două cadre

Pentru validare, avem nevoie de o modalitate prin care o pagină terță să poată interoga valoarea ickt și să o valideze. Facem acest lucru prin încorporarea site-ului terț în cadrul unui <iframe> într-o pagină de la originea securizată și prin injectarea unei bucăți de JavaScript în site-ul terț. Construim un cadru exterior securizat și un cadru interior al terților.

Cadru interior

În cadrul cadrului interior, injectăm un script în fiecare pagină proxiată pe care o servim. De asemenea, împreună cu acesta, injectăm valoarea ickt calculată din ick văzută în cerere. Comportamentul cadrului interior este următorul:

  1. Verificare cu cadrul exterior:
    • postMessage în partea de sus cu ickt încorporat în pagină.
    • Așteptați.
    • Dacă scriptul primește o confirmare de la originea securizată, lăsăm utilizatorul să interacționeze cu pagina.
    • Dacă scriptul așteaptă prea mult sau primește un răspuns de la o origine neașteptată, vom naviga cadrul către un ecran de eroare fără conținut terț (pagina noastră „Oops”), deoarece este posibil ca cadrul exterior să nu fie acolo sau să fie diferit de ceea ce se așteaptă cadrul interior.
  2. Verificați cu parent:
    • postMessage la parent.
    • Așteptați.
    • Dacă scriptul primește un răspuns cu source===parent și origine sub .0.discoverapp.com, va continua.
    • Dacă scriptul așteaptă prea mult sau primește un răspuns de la o origine neașteptată, vom naviga la pagina „Oops”.

Câteva note despre cadrul interior:

  1. Chiar dacă este ocolit, potențialii atacatori ar putea fixa doar pe o origine pe care pot obține executarea de cod, ceea ce face ca vectorii de fixare a cookie-urilor să fie redundanți.
  2. Supunem că o origine benignă nu va ocoli în mod deliberat protocolul de mesagerie interior-exterior.

Cadrul exterior

Cadrul exterior este acolo pentru a atesta că cadrul interior este coerent:

  1. Ne asigurăm că cadrul exterior este întotdeauna cadrul superior cu JavaScript și X-Frame-Options: DENY.
  2. Așteptați postMessage.
  3. Dacă cadrul exterior primește un mesaj:
    • Este de la o origine a cadrului interior?
    • Dacă da, raportează valoarea corectă ickt?
      • Dacă da, trimiteți un mesaj de confirmare.
      • Dacă nu, ștergeți sesiunea, ștergeți toate cookie-urile și navigați către o origine sigură.
  4. Dacă cadrul exterior nu primește un mesaj timp de câteva secunde sau dacă subcadrul nu este cel mai de sus cadru interior, eliminăm locația din bara de adrese a cadrului sigur.

Interacțiunea cu pagina

Pentru a evita condițiile de cursă în care o persoană ar putea introduce o parolă sub un cookie fixat înainte ca cadrul interior să fi finalizat verificarea, este important să împiedicăm persoanele să interacționeze cu pagina înainte ca secvența de verificare a cadrului interior să se finalizeze.

Pentru a preveni acest lucru, serverul adaugă style="display:none" la elementul <html> al fiecărei pagini. Cadrul interior îl va elimina atunci când primește confirmarea cadrului exterior.

Codul JavaScript are în continuare voie să ruleze, iar resursele sunt în continuare preluate. Dar, atâta timp cât persoana nu a introdus nicio informație în pagină, browserul nu face nimic din ceea ce un potențial atacator nu ar fi putut face prin simpla vizitare a site-ului – cu excepția cazului în care site-ul este deja vulnerabil la falsificarea cererilor încrucișate pe site (CSRF).

Prin alegerea acestei soluții, a trebuit apoi să rezolvăm și alte rezultate posibile, în special:

  1. Fixarea sincronă a cookie-urilor.
  2. Clickjacking din cauza framing-ului.
  3. Phishing-ul care se substituie domeniului Descoperă.

Fixarea sincronă a cookie-urilor

Până în acest moment, protecțiile pe care le-am implementat au luat în considerare fixările sincrone, dar acestea pot apărea și în mod asincron. Pentru a preveni acest lucru, folosim o metodă clasică de prevenire CSRF. Solicităm ca POST-urile să poarte un parametru de interogare cu datr văzut la încărcarea paginii. Apoi, comparăm parametrul de interogare cu cookie-ul datr văzut în cerere. Dacă nu se potrivesc, nu îndeplinim cererea.

Pentru a evita scurgerea datr, încorporăm o versiune criptată a datr în interiorul cadrului interior și ne asigurăm că acest parametru de interogare este adăugat la fiecare obiect <form> și XHR. Deoarece pagina nu poate deriva singură simbolul datr, datr adăugat este cel văzut în acel moment.

Pentru cererile anonime, solicităm ca acestea să aibă și parametrul de interogare datr. Anonimatul este păstrat pentru că nu îl scurgem către site-ul terț – cookie-ul ick lipsește, deci nu putem folosi borcanul cu cookie-uri. Cu toate acestea, în acest caz, nu suntem în măsură să validăm în funcție de cookie-ul datr, astfel încât POST-urile anonime pot fi efectuate în cadrul sesiunilor fixate. Dar, din moment ce sunt anonime și le lipsește ick, nu se pot scurge informații sensibile.

Clickjacking

Când un site trimite X-Frame-Options: DENY, acesta nu se va încărca într-un cadru interior. Acest antet este utilizat de site-urile web pentru a preveni expunerea la anumite tipuri de atacuri, cum ar fi clickjacking. Eliminăm acest antet din răspunsul HTTP, dar cerem cadrului interior să verifice că parent este cadrul ferestrei top folosind postMessage. Dacă validarea eșuează, navigăm utilizatorul către pagina „Oops”.

Phishing

„Bara de adrese” pe care o furnizăm în cadrul securizat este utilizată pentru a expune utilizatorului originea cadrului interior cea mai de sus. Cu toate acestea, ea poate fi copiată de site-urile de phishing care se dau drept Discover. Împiedicăm legăturile malițioase să navigheze departe de Discover prin împiedicarea navigării în partea de sus folosind <iframe sandbox>. Cadrul exterior poate fi evadat numai prin navigarea directă către un alt site.

Customside cookies

Cuvintele cookie de pe partea clientului document.cookie permit JavaScript să citească și să modifice cookie-urile care nu sunt marcate HttpOnly. Susținerea în siguranță a acestui lucru este o provocare într-un sistem care păstrează cookie-urile pe server.

Accesarea cookie-urilor: Atunci când se primește o cerere, proxy-ul va enumera toate cookie-urile care sunt vizibile pentru originea respectivă. Acesta va atașa apoi o sarcină utilă JSON la pagina de răspuns. Codul de pe partea clientului este injectat pentru a shimba document.cookie și a face aceste cookie-uri vizibile pentru alte scripturi, ca și cum ar fi cookie-uri reale de pe partea clientului.

Modificarea cookie-urilor: Dacă scripturilor li se permite să seteze în mod arbitrar cookie-uri pe care serverul le acceptă apoi, acest lucru ar putea duce la fixare, în cazul în care originea evil.com ar putea seta un cookie sensibil pe example.com.

Încrederea în capacitățile CORS ale browserului nu ar fi suficientă în acest caz – originea a.example.com care încearcă să seteze un cookie pe example.com va fi blocată de browser, deoarece aceste origini sunt frați și nu sunt ierarhice.

Chiar și așa, atunci când serverul primește un nou cookie setat de client, nu poate impune în mod sigur dacă domeniul țintă este permis; originea scriitorului este cunoscută doar de client și nu este întotdeauna trimisă serverului într-un mod în care putem avea încredere.

Pentru a forța clientul să dovedească faptul că este eligibil pentru a seta cookie-uri pe un anumit domeniu, serverul va trimite, în plus față de sarcina utilă JSON, o listă de token-uri criptografice pentru fiecare dintre originile la care originea solicitantă este autorizată să seteze cookie-uri. Aceste token-uri sunt sărate cu valoarea ick, astfel încât nu pot fi transferate între utilizatori.

Shim-ul de pe partea clientului pentru document.cookie se ocupă de rezolvarea și încorporarea token-ului în textul efectiv al cookie-ului care este trimis către proxy. Proxy-ul poate verifica apoi dacă originea de scriere a posedat într-adevăr token-ul pentru a scrie în domeniul țintă al cookie-ului și îl stochează în borcanul de cookie-uri de pe partea serverului, trimițându-l din nou clientului la următoarea solicitare a paginii.

Protocolul Bootstrap

Modelul conține trei tipuri de origine: origine portal (portal Discover, etc.), origine securizată (cadru exterior) și origine de rescriere (cadru interior). Fiecare are o nevoie diferită:

  1. Originea portal necesită datr.
  2. Originea securizată necesită ickt.
  3. Originea de rescriere necesită datr și ick.

Cu protocolul localStorage

Iată o reprezentare a procesului de bootstrap pentru majoritatea browserelor mobile moderne:

Este important de reținut că, pentru a evita reflexia, punctul final de bootstrap de la originea securizată emite întotdeauna un nou ick și ickt; ick nu depinde niciodată de intrarea utilizatorului. Rețineți că, deoarece am setat domain=.discoverapp.com atât pe ick, cât și pe datr, acestea sunt disponibile în toate tipurile de origine, iar ickt este disponibil numai în originea securizată.

Fără protocolul localStorage

Pentru că anumite browsere, cum ar fi Opera Mini (popular în multe țări în care operează Discover), nu acceptă localStorage, nu putem stoca valorile ick și ickt. Acest lucru înseamnă că trebuie să folosim un protocol diferit:

Am decis să separăm originea de rescriere de originea securizată, astfel încât acestea să nu împartă același sufix de gazdă, conform listei publice de sufixe. Folosim www.0.discoverapp.com pentru a stoca copia securizată a ickt (ca un cookie) și mutăm toate originile terților sub 0.i.org. Într-un browser care se comportă bine, setarea unui cookie pe originea securizată o va face inaccesibilă pentru toate originile de rescriere.

Din moment ce originile sunt acum separate, procesul nostru de bootstrap devine un proces în doi pași. Înainte, puteam seta ick în aceeași cerere în care provizionam localStorage cu ickt. Acum, trebuie să inițializăm două origini, în cereri separate, fără a deschide vectori de fixare ick.

Soluționăm acest lucru inițializând mai întâi originea securizată cu cookie-ul ickt și oferind utilizatorului o versiune criptată a ick, cu o cheie cunoscută doar de către proxy. Textul cifrat ick este însoțit de un nonce care poate fi folosit pentru a decripta acel ick particular în originea de rescriere și pentru a seta un cookie, dar numai o singură dată.

Un atacator ar putea alege fie:

  1. Utiliza nonce-ul pentru a dezvălui cookie-ul ick.
  2. Pasându-l utilizatorului pentru a-i fixa valoarea.

În ambele cazuri, atacatorul nu poate cunoaște și forța simultan o anumită valoare ick asupra unui utilizator. Procesul sincronizează, de asemenea, datr între origini.

Această arhitectură a fost supusă unor teste de securitate interne și externe substanțiale. Credem că am dezvoltat un design care este suficient de robust pentru a rezista tipurilor de atacuri asupra aplicațiilor web pe care le vedem în natură și pentru a oferi în siguranță o conectivitate sustenabilă pentru operatorii de telefonie mobilă. În urma lansării Discover în Peru, plănuim să desfășurăm teste Discover suplimentare cu operatori parteneri într-o serie de alte țări în care am testat în versiune beta caracteristicile produsului, inclusiv în Thailanda, Filipine și Irak. Anticipăm că Discover va fi operațional în aceste țări suplimentare în următoarele săptămâni și vom explora teste suplimentare acolo unde operatorii parteneri doresc să participe.

Am dori să îi mulțumim lui Berk Demir pentru ajutorul său în această lucrare.

Într-un efort de a fi mai incluzivi în limbajul nostru, am editat această postare pentru a înlocui „whitelist” cu „allowlist.”

By: adminPosted on

Lasă un răspuns

Adresa ta de email nu va fi publicată.