Hogyan működnek a böngészők

Bevezetés a webalkalmazások biztonságába

Nyissuk meg ezt a sorozatot a Web Application Security webhelyen annak magyarázatával, hogy mit és hogyan csinálnak a böngészők. Mivel az ügyfelek többsége böngészőn keresztül fog interakcióba lépni az Ön webalkalmazásával, feltétlenül meg kell értenie e csodálatos programok alapjait.

A böngésző renderelő motor . Feladata egy weboldal letöltése és az ember számára érthető módon történő megjelenítése.

Annak ellenére, hogy ez szinte bűnözői túlegyszerűsítés, egyelőre csak ezt kell tudnunk.

  • A felhasználó megad egy címet a böngészősávban.
  • A böngésző letölti a „dokumentumot” az adott URL-címen, és megjeleníti.

Lehet, hogy hozzászokott az egyik legnépszerűbb böngészőhöz, például a Chrome-hoz, a Firefox-hoz, az Edge-hez vagy a Safarihoz, de ez nem azt jelenti, hogy nincsenek különféle böngészők.

A hiúz például egy könnyű, szöveges böngésző, amely a parancssorból működik. A hiúz középpontjában ugyanazok az elvek rejlenek, amelyeket bármely más „mainstream” böngészőben megtalálhatna. A felhasználó megad egy webcímet (URL), a böngésző beolvassa a dokumentumot és megjeleníti - az egyetlen különbség az a tény, hogy a hiúz nem vizuális megjelenítő motort használ, hanem inkább szöveges felületet, amely a Google-hez hasonló webhelyeket így néz ki :

Nagyjából megértjük, hogy mit csinál a böngésző, de nézzük meg közelebbről azokat a lépéseket, amelyeket ezek a leleményes alkalmazások megtesznek számunkra.

Mit csinál a böngésző?

Röviden, a böngésző feladata főleg a következőkből áll:

  • DNS-felbontás
  • HTTP csere
  • Rendering
  • Öblítse le és ismételje meg

DNS-felbontás

Ez a folyamat biztosítja, hogy amint a felhasználó megad egy URL-t, a böngésző tudja, melyik szerverhez kell csatlakoznia. A böngésző kapcsolatba lép egy DNS-szerverrel, hogy megtalálja azt, amely google.comlefordítja azt 216.58.207.110az IP-címet, amelyhez a böngésző csatlakozhat.

HTTP csere

Miután a böngésző azonosította, hogy melyik szerver fogja kiszolgálni a kérésünket, TCP kapcsolatot kezdeményez vele és megkezdi a HTTP cserét . Ez nem más, mint a böngésző módja a szerverrel való kommunikációra, amire szüksége van, és a szerver válaszolhat.

A HTTP egyszerűen az internetes kommunikáció legnépszerűbb protokolljának a neve, és a böngészők többnyire HTTP-n keresztül beszélnek, amikor a szerverekkel kommunikálnak. Egy HTTP csere során az ügyfél (a böngésző) küld egy kérést , és a kiszolgáló megválaszolása vissza a válasz .

Például, miután a böngésző sikeresen csatlakozott a mögöttes kiszolgálóhoz google.com, a következőképpen küld egy kérést:

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

Bontjuk soronként a kérést:

  • GET / HTTP/1.1: Ezzel az első sorban, a böngésző megkérdezi a szerver letölteni a dokumentumot a helyen /, hozzátéve, hogy a többi kérés követi a HTTP / 1.1 protokollt (ez is lehet használni 1.0, vagy 2)
  • Host: google.com: ez az egyetlen HTTP fejléc, amely kötelező a HTTP / 1.1 fájlban . Mivel a kiszolgáló több tartományt is kiszolgálhat ( google.com, google.co.ukstb.), Az ügyfél itt megemlíti, hogy a kérés az adott gazdagépre vonatkozott
  • Accept: */*: opcionális fejléc, ahol a böngésző azt mondja a szervernek, hogy bármilyen visszajelzést elfogad. A szerver rendelkezhet olyan erőforrással, amely elérhető JSON, XML vagy HTML formátumban, így kiválaszthatja, hogy melyik formátumot részesíti előnyben

Miután az ügyfélként működő böngésző elvégezte a kérését, a szerveren a sor, hogy válaszoljon. Így néz ki egy válasz:

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
......

Hú, ez sok információ megemésztendő. A szerver tudatja velünk, hogy a kérés sikeres volt ( 200 OK), és hozzáad néhány fejlécet a válaszhoz , például azt hirdeti, hogy melyik szerver dolgozta fel a kérésünket ( Server: gws), mi X-XSS-Protectionennek a válasznak a házirendje és így tovább és így tovább.

Most nem kell megértenie a válasz minden egyes vonalát. A sorozat későbbiekben a HTTP protokollra, annak fejlécére és így tovább fogunk foglalkozni.

Egyelőre csak annyit kell megértenie, hogy az ügyfél és a szerver információt cserélnek, és hogy ezt HTTP-n keresztül teszik meg.

Rendering

Végül, de nem utolsósorban a megjelenítési folyamat. Mennyire lenne jó egy böngésző, ha az egyetlen dolog, amit a felhasználónak megmutatna, egy vicces karakterek listája?

......

A válasz törzsében a szerver tartalmazza a válasz Content-Typefejléc szerinti ábrázolását . Esetünkben a tartalom típusát állítottuk be text/html, ezért HTML-jelöléssel számolunk a válaszban - pontosan ezt találjuk a testben.

Itt igazán ragyog egy böngésző. Elemzi a HTML-t, további erőforrásokat tölt be a jelölésben (például lehetnek Java fájlok vagy CSS dokumentumok), és a lehető leghamarabb bemutatja azokat a felhasználónak.

Még egyszer, a végeredmény olyasmi, amit Joe átlagosan megért.

Ha egy böngésző címsorába nyomjuk az Enter billentyűt, annak részletesebb változatához azt javaslom, hogy olvassa el a „Mi történik, amikor…” elnevezést, amely egy nagyon kidolgozott kísérlet a folyamat mögött meghúzódó mechanika magyarázatára.

Mivel ez a biztonságra összpontosító sorozat, el fogok engedni egy tippet arra vonatkozóan, amit most tanultunk: a támadók könnyen megélnek a HTTP-csere és a renderelés részének sebezhetőségéből . A biztonsági rések és a rosszindulatú felhasználók másutt is leselkednek, de a jobb biztonsági megközelítés ezen a szinten már lehetővé teszi, hogy lépéseket tegyen a biztonsági testtartás javításában.

Szállítók

A 4 legnépszerűbb böngésző különböző gyártókhoz tartozik:

  • Chrome a Google-tól
  • Firefox a Mozillától
  • Safari az Apple-től
  • Edge by Microsoft

A piaci penetráció növelése érdekében az árusok egymással való küzdelem mellett az internetes szabványok fejlesztése érdekében is együttműködnek egymással , amelyek egyfajta „minimumkövetelmények” a böngészők számára.

A W3C a testület a szabványok fejlesztésének hátterében, de nem szokatlan, hogy a böngészők saját funkciókat fejlesztenek ki, amelyek végül web-szabványokká teszik, és ez alól a biztonság sem kivétel.

A Chrome 51 például bevezette a SameSite cookie-kat, egy olyan funkciót, amely lehetővé teszi a webalkalmazások számára, hogy megszabaduljanak a CSRF néven ismert bizonyos típusú sebezhetőségektől (erről bővebben később). Más gyártók úgy döntöttek, hogy ez jó ötlet, és követték a példájukat, ami a SameSite internetes szabványt eredményezte: mostantól a Safari az egyetlen nagyobb böngésző, amely nem támogatja a SameSite cookie-kat.

Ez 2 dolgot mond el nekünk:

  • Úgy tűnik, hogy a Safari nem törődik eléggé a felhasználók biztonságával (csak vicceltem: a SameSite sütik elérhetők lesznek a Safari 12-ben, amely valószínűleg már megjelent a cikk elolvasásáig)
  • A biztonsági rés javítása egy böngészőben nem jelenti azt, hogy az összes felhasználó biztonságban van

Az első pont a Safarira lövés (mint említettem, csak vicceltem!), Míg a második pont nagyon fontos. A webalkalmazások fejlesztésekor nem csak arra kell figyelnünk, hogy a különböző böngészőkben ugyanúgy nézzenek ki, hanem arról is, hogy a felhasználóinkat ugyanolyan módon védjék a platformok.

A webbiztonsági stratégiának attól függően változhat, hogy a böngésző szállítója mit enged meg nekünk . Manapság a legtöbb böngésző ugyanazt a funkciókat támogatja, és ritkán tér el a közös ütemtervtől, de a fentihez hasonló esetek még mindig előfordulnak, és ezt figyelembe kell vennünk biztonsági stratégiánk meghatározása során.

Esetünkben, ha úgy döntünk, hogy a CSRF-támadásokat csak a SameSite sütikön keresztül fogjuk enyhíteni, akkor tudatában kell lennünk annak, hogy a Safari-felhasználóinkat kockáztatjuk. És ezt a felhasználóinknak is tudnia kell.

Végül, de nem utolsósorban, ne feledje, hogy eldöntheti, hogy támogatja-e a böngésző verzióját, vagy sem: az egyes böngészőverziók támogatása nem praktikus (gondoljunk csak az Internet Explorer 6-ra). Annak biztosítása, hogy a nagy böngészők utolsó verziói támogatottak, általában jó döntés. Ha azonban nem egy adott platformon tervez védelmet nyújtani, akkor általában ajánlatos értesíteni a felhasználókat.

Szakértői tipp : Soha ne ösztönözze a felhasználókat elavult böngészők használatára, és ne támogassa őket aktívan. Annak ellenére, hogy esetleg megtette az összes szükséges óvintézkedést, más webfejlesztők nem tették meg. Arra ösztönzi a felhasználókat, hogy használják az egyik legfontosabb böngésző legújabb támogatott verzióját.

Szállító vagy standard hiba?

Az a tény, hogy az átlagos felhasználó egy harmadik fél kliensén (a böngészőn) keresztül jut el alkalmazásunkhoz, az egyértelmű és biztonságos böngészési élmény felé újabb indirekt szintet ad: maga a böngésző biztonsági rést okozhat.

Az eladók általában jutalmakat (más néven hibajavításokat ) nyújtanak azoknak a biztonsági kutatóknak, akik sebezhetőséget találhatnak magában a böngészőben. Ezek a hibák nem a megvalósításhoz vannak kötve, hanem ahhoz, hogy a böngésző hogyan kezeli a biztonságot egyedül.

The Chrome reward program, for example, lets security engineers reach out to the Chrome security team to report vulnerabilities they have found. If these vulnerabilities are confirmed, a patch is issued, a security advisory notice is generally released to the public, and the researcher receives a (usually financial) reward from the program.

Companies like Google invest a relatively good amount of capital into their Bug Bounty programs, as it allows them to attract researchers by promising a financial benefit should they find any problem with the application.

In a Bug Bounty program, everyone wins: the vendor manages to improve the security of its software, and researchers get paid for their findings. We will discuss these programs later on, as I believe Bug Bounty initiatives deserve their own section in the security landscape.

Jake Archibald is a developer advocate at Google who recently discovered a vulnerability impacting more than one browser. He documented his efforts, how he approached different vendors, and their reactions in an interesting blog post that I’d recommend you read.

A browser for developers

By now, we should have understood a very simple but rather important concept: browsers are simply HTTP clients built for the average internet surfer.

They are definitely more powerful than a platform’s bare HTTP client (think of NodeJS’s require('http'), for example), but at the end of the day, they’re “just” a natural evolution of simpler HTTP clients.

As developers, our HTTP client of choice is probably cURL by Daniel Stenberg, one of the most popular software programs web developers use on a daily basis. It allows us to do an HTTP exchange on-the-fly, by sending an HTTP request from our command line:

$ 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

In the example above, we have requested the document at localhost:8080/, and a local server replied successfully.

Rather than dumping the response’s body to the command line, here we’ve used the -I flag which tells cURL we’re only interested in the response headers. Taking it one step forward, we can instruct cURL to dump a little more information, including the actual request it performs, so that we can have a better look at this whole HTTP exchange. The option we need to use is -v (verbose):

$ 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

Just about the same information is available in mainstream browsers through their DevTools.

As we’ve seen, browsers are nothing more than elaborate HTTP clients. Sure, they add an enormous amount of features (think of credential management, bookmarking, history, etc) but the truth is that they were born as HTTP clients for humans. This is important, as in most cases you don’t need a browser to test your web application’s security, as you can simply “curl it” and have a look at the response.

One final thing that I’d like to point out, is that anything can be a browser. If you have a mobile application that consumes APIs through the HTTP protocol, then the app is your browser — it just happens to be a highly customized one you built yourself, one that only understands a specific type of HTTP responses (from your own API).

Into the HTTP protocol

As we mentioned, the HTTP exchange and rendering phases are the ones that we’re mostly going to cover, as they provide the largest number of attack vectors for malicious users.

In the next article, we’re going to take a deeper look at the HTTP protocol and try to understand what measures we should take in order to secure HTTP exchanges.

Originally published at odino.org (29 July 2018).

You can follow me on Twitter - rants are welcome! ?