de Alex Nadalin

Cum funcționează browserele

Introducere în securitatea aplicațiilor web

Cum functioneaza browserele
Fotografie de Liam Tucker pe Unsplash

Să deschidem această serie pe Securitatea aplicațiilor web cu o explicație a ceea ce fac browserele și cum o fac. Deoarece majoritatea clienților dvs. vor interacționa cu aplicația dvs. web printr-un browser, este imperativ să înțelegeți elementele de bază ale acestor programe minunate.

Browserul este un motor de redare. Sarcina sa este de a descărca o pagină web și a o reda într-un mod ușor de înțeles de către o ființă umană.

Chiar dacă aceasta este o simplificare excesivă aproape criminală, este tot ce trebuie să știm pentru moment.

  • Utilizatorul introduce o adresă în bara browserului.
  • Browserul descarcă „documentul” la adresa URL respectivă și îl redă.
Cum functioneaza browserele

S-ar putea să fiți obișnuit să lucrați cu unul dintre cele mai populare browsere precum Chrome, Firefox, Edge sau Safari, dar asta nu înseamnă că nu există browsere diferite.

râsul, de exemplu, este un browser ușor, bazat pe text, care funcționează din linia de comandă. În centrul linxului se află aceleași principii exacte pe care le-ați găsi în orice alte browsere „mainstream”. Un utilizator introduce o adresă web (URL), browserul preia documentul și îl redă – singura diferență fiind faptul că râsul nu folosește un motor de redare vizuală, ci mai degrabă o interfață bazată pe text, ceea ce face ca site-urile web precum Google să arate astfel :

1611637811 943 Cum functioneaza browserele

Înțelegem în general ce face un browser, dar să aruncăm o privire mai atentă la pașii pe care îi fac aceste aplicații ingenioase pentru noi.

Ce face un browser?

Pe scurt, sarcina unui browser constă în principal din:

  • Rezoluție DNS
  • Schimb HTTP
  • Redare
  • Clătiți și repetați

Rezoluție DNS

Acest proces asigură faptul că, odată ce utilizatorul introduce o adresă URL, browserul știe la ce server trebuie să se conecteze. Browserul contactează un server DNS pentru a găsi acest lucru google.com se traduce în 216.58.207.110, o adresă IP la care browserul se poate conecta.

Schimb HTTP

Odată ce browserul a identificat ce server va servi cererea noastră, va iniția o conexiune TCP cu acesta și va începe Schimb HTTP. Aceasta nu este altceva decât o modalitate prin care browserul poate comunica cu serverul de ce are nevoie și pentru ca serverul să răspundă înapoi.

HTTP este pur și simplu numele celui mai popular protocol pentru comunicarea pe web, iar browserele vorbesc mai ales prin HTTP atunci când comunică cu serverele. Un schimb HTTP implică trimiterea unui client (browserul nostru) cerere, iar serverul răspunde înapoi cu un raspuns.

De exemplu, după ce browserul s-a conectat cu succes la serverul din spate google.com, va trimite o cerere care arată ca următoarea:

GET / HTTP/1.1Host: google.comAccept: */*

Să descompunem cererea, rând cu rând:

  • GET / HTTP/1.1: cu această primă linie, browserul cere serverului să recupereze documentul la locație /, adăugând că restul cererii va urma protocolul HTTP / 1.1 (s-ar putea utiliza și 1.0 sau 2)
  • Host: google.com: aceasta este singurul antet HTTP obligatoriu în HTTP / 1.1. Deoarece serverul poate deservi mai multe domenii (google.com, google.co.uk, etc) clientul de aici menționează că solicitarea a fost pentru gazda respectivă
  • Accept: */*: un antet opțional, unde browserul îi spune serverului că va accepta orice fel de răspuns. Serverul ar putea avea o resursă disponibilă în formatele JSON, XML sau HTML, deci poate alege oricare format preferă

După browser, care acționează ca un client, se face cu solicitarea sa, este rândul serverului să răspundă înapoi. Așa arată un răspuns:

HTTP/1.1 200 OKCache-Control: private, max-age=0Content-Type: text/html; charset=ISO-8859-1Server: gwsX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINSet-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly
<!doctype html><html">......</html>

Ei, sunt o mulțime de informații de digerat. Serverul ne anunță că solicitarea a avut succes (200 OK) și adaugă câteva anteturi la raspuns, de exemplu, anunță ce server a procesat solicitarea noastră (Server: gws), ce este X-XSS-Protection politica acestui răspuns și așa mai departe și așa mai departe.

În acest moment, nu trebuie să înțelegeți fiecare linie din răspuns. Vom acoperi protocolul HTTP, antetele acestuia și așa mai departe în această serie.

Deocamdată, tot ce trebuie să înțelegeți este că clientul și serverul fac schimb de informații și că fac acest lucru prin HTTP.

Redare

Nu în ultimul rând, redare proces. Cât de bun ar fi un browser dacă singurul lucru pe care l-ar arăta utilizatorului este o listă de personaje amuzante?

<!doctype html><html">......</html>

În corp din răspuns, serverul include reprezentarea răspunsului în conformitate cu Content-Type antet. În cazul nostru, tipul de conținut a fost setat la text/html, așa că ne așteptăm la marcarea HTML în răspuns – care este exact ceea ce găsim în corp.

Aici strălucește cu adevărat un browser. Acesta analizează codul HTML, încarcă resurse suplimentare incluse în marcaj (de exemplu, ar putea fi fișiere JavaScript sau documente CSS de preluat) și le prezintă utilizatorului cât mai curând posibil.

Încă o dată, rezultatul final este ceva pe care Joe îl poate înțelege.

1611637811 257 Cum functioneaza browserele

Pentru o versiune mai detaliată a ceea ce se întâmplă cu adevărat atunci când apăsăm Enter în bara de adrese a unui browser, aș sugera să citiți „Ce se intampla cand…”, O încercare foarte elaborată de a explica mecanica din spatele procesului.

Deoarece aceasta este o serie axată pe securitate, voi lăsa un indiciu asupra a ceea ce tocmai am învățat: atacatorii își câștigă cu ușurință existența din vulnerabilități în partea de schimb și redare HTTP. Vulnerabilitățile și utilizatorii rău intenționați se ascund și în altă parte, dar o abordare mai bună a securității la aceste niveluri vă permite deja să faceți pași în îmbunătățirea poziției dvs. de securitate.

Furnizori

Cele mai populare 4 browser-uri aparțin diferiților furnizori:

  • Chrome de la Google
  • Firefox de Mozilla
  • Safari de la Apple
  • Edge de la Microsoft

Pe lângă faptul că se luptă între ei pentru a-și crește penetrarea pe piață, vânzătorii se angajează, de asemenea, unul cu celălalt pentru a se îmbunătăți standarde web, care reprezintă un fel de „cerințe minime” pentru browsere.

W3C este organismul din spatele dezvoltării standardelor, dar nu este neobișnuit ca browserele să-și dezvolte propriile caracteristici care, în cele din urmă, să devină standarde web, iar securitatea nu face excepție de la asta.

Chrome 51, de exemplu, a introdus cookie-uri SameSite, o caracteristică care ar permite aplicațiilor web să scape de un anumit tip de vulnerabilitate cunoscut sub numele de CSRF (mai multe despre aceasta mai târziu). Alți furnizori au decis că aceasta este o idee bună și au urmat exemplul, ceea ce a făcut ca SameSite să fie un standard web: de acum, Safari este singurul browser major fără suport pentru cookie-uri SameSite.

1611637811 195 Cum functioneaza browserele

Aceasta ne spune 2 lucruri:

  • Safari nu pare să se preocupe suficient de mult de securitatea utilizatorilor lor (glumesc: cookie-urile SameSite vor fi disponibile în Safari 12, care ar fi putut fi lansate deja în momentul în care citiți acest articol)
  • corecția unei vulnerabilități pe un browser nu înseamnă că toți utilizatorii dvs. sunt în siguranță

Primul punct este o lovitură la Safari (așa cum am menționat, glumesc!), În timp ce al doilea punct este cu adevărat important. Atunci când dezvoltăm aplicații web, nu trebuie doar să ne asigurăm că arată la fel în diferite browsere, ci și că ne asigură că utilizatorii noștri sunt protejați în același mod pe platforme.

Strategia dvs. de securitate web ar trebui să varieze în funcție de ceea ce ne permite furnizorul unui browser. În zilele noastre, majoritatea browserelor acceptă același set de caracteristici și rareori se abat de la foaia de parcurs comună, dar instanțe precum cea de mai sus se întâmplă și este ceva de care trebuie să ținem cont atunci când ne definim strategia de securitate.

În cazul nostru, dacă decidem că vom atenua atacurile CSRF numai prin intermediul cookie-urilor SameSite, ar trebui să fim conștienți că punem în pericol utilizatorii noștri Safari. Și utilizatorii noștri ar trebui să știe și asta.

Nu în ultimul rând, trebuie să vă amintiți că puteți decide dacă acceptați sau nu o versiune de browser: acceptarea fiecărei versiuni de browser ar fi impracticabilă (gândiți-vă la Internet Explorer 6). Asigurarea faptului că ultimele câteva versiuni ale principalelor browsere sunt acceptate, totuși, este în general o decizie bună. Cu toate acestea, dacă nu intenționați să oferiți protecție pe o anumită platformă, este recomandabil să informați utilizatorii.

Sfat Pro: Nu trebuie să vă încurajați niciodată utilizatorii să utilizeze browsere învechite sau să le susțineți în mod activ. Chiar dacă este posibil să fi luat toate măsurile de precauție necesare, este posibil ca alți dezvoltatori web să nu fi luat. Încurajați utilizatorii să utilizeze cea mai recentă versiune acceptată a unuia dintre principalele browsere.

Furnizor sau eroare standard?

Faptul că utilizatorul mediu accesează aplicația noastră printr-un client terță parte (browserul) adaugă un alt nivel de indirectare către o experiență de navigare clară și sigură: browserul în sine ar putea prezenta o vulnerabilitate de securitate.

În general, furnizorii oferă recompense (aka recompense de bug-uri) cercetătorilor în materie de securitate care pot găsi o vulnerabilitate pe browserul propriu-zis. Aceste erori nu sunt legate de implementarea dvs., ci mai degrabă de modul în care browserul gestionează singur securitatea.

Programul de recompensă Chrome, de exemplu, permite inginerilor de securitate să contacteze echipa de securitate Chrome pentru a raporta vulnerabilitățile pe care le-au găsit. Dacă aceste vulnerabilități sunt confirmate, este emis un patch, o notificare de securitate este în general publicată publicului, iar cercetătorul primește o recompensă (de obicei financiară) din partea programului.

Companii precum Google investesc o cantitate relativ bună de capital în programele lor Bug Bounty, deoarece le permite să atragă cercetători promițând un beneficiu financiar în cazul în care găsesc vreo problemă cu aplicația.

Într-un program Bug Bounty, toată lumea câștigă: furnizorul reușește să îmbunătățească securitatea software-ului său, iar cercetătorii sunt plătiți pentru descoperirile lor. Vom discuta aceste programe mai târziu, deoarece cred că inițiativele Bug Bounty merită propria lor secțiune în peisajul securității.

Jake Archibald este un avocat al dezvoltatorilor de la Google, care a descoperit recent o vulnerabilitate care afectează mai mult de un browser. El și-a documentat eforturile, modul în care a abordat diferiți furnizori și reacțiile acestora într-un mod interesant postare pe blog că ți-aș recomanda să citești.

Un browser pentru dezvoltatori

Până acum, ar fi trebuit să înțelegem un concept foarte simplu, dar destul de important: browserele sunt pur și simplu clienți HTTP construiți pentru surferul mediu de internet.

Sunt cu siguranță mai puternici decât clientul HTTP gol al unei platforme (gândiți-vă la NodeJS require('http'), de exemplu), dar la sfârșitul zilei, acestea sunt „doar” o evoluție naturală a clienților HTTP mai simpli.

În calitate de dezvoltatori, clientul nostru HTTP preferat este probabil răsuci de Daniel Stenberg, unul dintre cele mai populare programe software pe care dezvoltatorii web îl folosesc zilnic. Ne permite să facem un schimb HTTP din mers, trimițând o cerere HTTP din linia noastră de comandă:

$ curl -I localhost:8080
HTTP/1.1 200 OKserver: ecstatic-2.2.1Content-Type: text/htmletag: "23724049-4096-"2018-07-20T11:20:35.526Z""last-modified: Fri, 20 Jul 2018 11:20:35 GMTcache-control: max-age=3600Date: Fri, 20 Jul 2018 11:21:02 GMTConnection: keep-alive

În exemplul de mai sus, am solicitat documentul la localhost:8080/, iar un server local a răspuns cu succes.

În loc să aruncăm corpul răspunsului pe linia de comandă, aici am folosit -I flag care spune cURL că suntem interesați doar de antetele de răspuns. Făcându-l cu un pas înainte, putem instrui CURL să arunce puțin mai multe informații, inclusiv cererea reală pe care o efectuează, astfel încât să putem arunca o privire mai bună asupra întregului schimb HTTP. Opțiunea pe care trebuie să o folosim este -v (detaliat):

$ curl -I -v localhost:8080* Rebuilt URL to: localhost:8080/*   Trying 127.0.0.1...* Connected to localhost (127.0.0.1) port 8080 (#0)> HEAD / HTTP/1.1> Host: localhost:8080> User-Agent: curl/7.47.0> Accept: */*>< HTTP/1.1 200 OKHTTP/1.1 200 OK< server: ecstatic-2.2.1server: ecstatic-2.2.1< Content-Type: text/htmlContent-Type: text/html< etag: "23724049-4096-"2018-07-20T11:20:35.526Z""etag: "23724049-4096-"2018-07-20T11:20:35.526Z""< last-modified: Fri, 20 Jul 2018 11:20:35 GMTlast-modified: Fri, 20 Jul 2018 11:20:35 GMT< cache-control: max-age=3600cache-control: max-age=3600< Date: Fri, 20 Jul 2018 11:25:55 GMTDate: Fri, 20 Jul 2018 11:25:55 GMT< Connection: keep-aliveConnection: keep-alive
<* Connection #0 to host localhost left intact

Aproape aceleași informații sunt disponibile în browserele obișnuite prin intermediul lor DevTools.

După cum am văzut, browserele nu sunt altceva decât clienți HTTP elaborați. Sigur, adaugă o cantitate enormă de caracteristici (gândiți-vă la gestionarea acreditării, marcaj, istoric etc.), dar adevărul este că s-au născut ca clienți HTTP pentru oameni. Acest lucru este important, deoarece, în majoritatea cazurilor, nu aveți nevoie de un browser pentru a testa securitatea aplicației dvs. web, deoarece puteți pur și simplu „curl-o” și arunca o privire asupra răspunsului.

Un ultim lucru pe care aș dori să-l subliniez este că orice poate fi un browser. Dacă aveți o aplicație mobilă care consumă API-uri prin protocolul HTTP, atunci aplicația este browserul dvs. – se întâmplă doar să fie una foarte personalizată pe care ați construit-o singură, una care înțelege doar un anumit tip de răspunsuri HTTP (din propriul API) .

În protocolul HTTP

După cum am menționat, Schimb HTTP și redare fazele sunt cele pe care le vom acoperi în cea mai mare parte, deoarece oferă cel mai mare număr vectori de atac pentru utilizatorii rău intenționați.

În articolul următor, vom analiza mai în profunzime protocolul HTTP și vom încerca să înțelegem ce măsuri ar trebui să luăm pentru a asigura schimburile HTTP.

Publicat inițial la odino.org (29 iulie 2018).
Poți să mă urmărești mai departe Stare de nervozitate – ranturile sunt binevenite! ?