Kratki uvod u web sigurnost

Programiranje

Priručnik za web programere o CORS-u, CSP-u, HSTS-u i svim kraticama web sigurnosti!

Postoji mnogo razloga za učenje o web sigurnosti, kao što su:

  • Zabrinuti ste korisnik koji se brine zbog curenja vaših osobnih podataka
  • Zabrinuti ste web programer koji želi učiniti svoje web aplikacije sigurnijima
  • Vi ste web programer koji se prijavljuje za poslove i želite biti spremni ako vas anketari postave pitanja o web sigurnosti

i tako dalje.

Pa, ovaj će post objasniti neke uobičajene kratice za web sigurnost na način koji je lako razumjeti, ali ipak točan.

Prije nego što to učinimo, pobrinimo se da razumijemo nekoliko temeljnih pojmova sigurnosti.

Dva temeljna koncepta sigurnosti

Nitko nikada nije 100% siguran.

Ne postoji pojam da ste 100% zaštićeni od hakiranja. Ako vam netko to ikad kaže, griješi.

Jedan sloj zaštite nije dovoljan.

Ne možete samo reći ...

Oh, jer sam implementirao CSP, siguran sam. Skriptiranje različitih web lokacija mogu prekrižiti sa svog popisa ranjivosti jer se to sada ne može dogoditi.

Možda je to nekima dato, ali lako je pronaći sebe da razmišljate na takav način. Mislim da je jedan od razloga zašto se programeri lako mogu zamisliti na takav način taj što je toliko kodiranja crno-bijelo, 0 ili 1, točno ili netačno. Sigurnost nije tako jednostavna.

Započet ćemo s onim s kojim se svatko susreće prilično rano na svom putu web razvoja. A onda pogledate StackOverflow i pronađete gomilu odgovora koji vam govore kako to zaobići.

Dijeljenje resursa s više podrijetla (CORS)

Jeste li ikad dobili pogrešku koja je izgledala otprilike ovako?

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Sigurno niste sami. A onda ga proguglate i netko vam kaže da nabavite ovo proširenje koje će ukloniti sve vaše probleme!

Super, zar ne?

CORS je tu da vas zaštiti, a ne ozlijedi!

Da bismo objasnili kako vam CORS pomaže, prvo razgovarajmo o kolačićima, posebno kolačićima za provjeru autentičnosti . Kolačići za provjeru autentičnosti koriste se da bi poslužitelju rekli da ste prijavljeni i automatski se šalju sa svim zahtjevima koje uputite tom poslužitelju.

Recimo da ste prijavljeni na Facebook, a oni koriste kolačiće za provjeru autentičnosti. Kliknete na bit.ly/r43nugikoji vas preusmjerava superevilwebsite.rocks. Skripta unutar superevilwebsite.rocksupućuje zahtjev na strani klijenta na facebook.comkoji šalje vaš kolačić za provjeru autentičnosti!

U svijetu bez CORS-a mogli bi unijeti promjene na vaš račun, a da vi to ni ne znate. Sve dok, naravno, ne postave bit.ly/r43nugina vašu vremensku traku i svi vaši prijatelji ne kliknu na nju, a zatim objave bit.ly/r43nugina svim vremenskim crtama vaših prijatelja, a zatim se ciklus nastavlja u zloj shemi koja prvo osvaja sve Facebook korisnike, a svijet proždire superevilwebsite.rocks. ?

Međutim, u svijetu CORS-a Facebook bi facebook.comna svom poslužitelju dopuštao samo zahtjeve s podrijetlom za uređivanje podataka. Drugim riječima, ograničili bi međusobno dijeljenje resursa. Tada možete pitati ...

Pa može li superevilwebsite.rocks samo promijeniti zaglavlje podrijetla na njihov zahtjev, tako da izgleda kao da dolazi s facebook.com?

Mogu pokušati, ali to neće uspjeti jer će ga preglednik jednostavno ignorirati i upotrijebiti stvarno podrijetlo.

Ok, ali što ako je superevilwebsite.rocks uputio zahtjev na strani poslužitelja?

U tom bi slučaju mogli zaobići CORS, ali neće pobijediti jer neće moći poslati vaš kolačić za provjeru autentičnosti tijekom vožnje. Skriptu bi trebalo izvršiti na klijentskoj strani da bi se dobio pristup kolačićima na vašoj klijentskoj strani.

Pravila o sigurnosti sadržaja (CSP)

Da bismo razumjeli CSP, prvo moramo razgovarati o jednoj od najčešćih ranjivosti na webu: XSS, što je skraćenica za skriptiranje na više web lokacija (yay - još jedan akronim).

XSS je slučaj kada neka zla osoba ubrizga JavaScript u kod vašeg klijenta. Možda mislite ...

Što će oni učiniti? Promijeniti boju iz crvene u plavu?

Pretpostavimo da je netko uspješno ubacio JavaScript u kod klijenta web stranice koju posjećujete.

Što bi mogli učiniti da bi bilo zlonamjerno?

  • Mogli bi upućivati ​​HTTP zahtjeve drugoj web lokaciji pretvarajući se da ste vi.
  • Mogli bi dodati oznaku sidra koja vas šalje na web mjesto koje izgleda identično onome na kojem se nalazite s nekim malo drugačijim, zlonamjernim karakteristikama.
  • Mogli bi dodati oznaku skripte s ugrađenim JavaScriptom.
  • Mogli bi dodati oznaku skripte koja negdje dohvaća udaljenu JavaScript datoteku.
  • Mogli bi dodati iframe koji pokriva stranicu i izgleda kao dio web stranice koji traži da unesete lozinku.

Mogućnosti su bezbrojne.

CSP pokušava spriječiti da se to dogodi ograničavajući:

  • što se može otvoriti u iframeu
  • koje se tablice stilova mogu učitati
  • gdje se mogu podnijeti zahtjevi itd.

Pa kako to funkcionira?

Kada kliknete na vezu ili upišete URL web stranice u adresnu traku preglednika, vaš preglednik šalje GET zahtjev. Na kraju se otvara do poslužitelja koji poslužuje HTML zajedno s nekim HTTP zaglavljima. Ako vas zanima koja zaglavlja primate, otvorite karticu Mreža na svojoj konzoli i posjetite neka web mjesta.

Možda ćete vidjeti zaglavlje odgovora koje izgleda ovako:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

To je politika sigurnosti sadržaja facebook.com. Preformatirajmo ga kako bismo ga lakše čitali:

content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Sada, hajde da raščlanimo direktive.

  • default-src ograničava sve ostale CSP direktive koje nisu izričito navedene.
  • script-srcograničava skripte koje se mogu učitati.
  • style-src ograničava tabele stilova koje se mogu učitati.
  • connect-src ograničava URL-ove koji se mogu učitati pomoću sučelja skripte, zato dohvatite, XHR, ajax itd.

Imajte na umu da postoji mnogo više CSP direktiva nego samo ove četiri gore prikazane. Preglednik će pročitati CSP zaglavlje i primijeniti te direktive na sve unutar HTML datoteke koja je poslužena. Ako su smjernice postavljene na odgovarajući način, dopuštaju samo ono što je potrebno.

Ako nije prisutno zaglavlje CSP-a, tada sve ide i ništa nije ograničeno. Gdje god vidite *, to je zamjenski znak. Možete zamisliti zamjenu *bilo čime i to će biti dopušteno.

HTTPS ili HTTP siguran

Svakako ste čuli za HTTPS. Možda ste čuli kako neki ljudi kažu ...

Zašto mi je stalo do upotrebe HTTPS-a ako sam samo na web mjestu i igram igru.

Ili ste možda čuli drugu stranu ...

Ludi ste ako vaša web stranica nema HTTPS. 2018. je godina! Ne vjerujte nikome tko kaže drugačije.

Možda ste čuli da će Chrome sada vašu web lokaciju označiti kao nesigurnu ako nije HTTPS.

U svojoj osnovi, HTTPS je prilično jednostavan. HTTPS je šifriran, a HTTP nije.

Pa zašto je to važno ako ne šaljete osjetljive podatke?

Pripremite se za još jednu kraticu ... MITM, što znači Čovjek u sredini.

Ako u kafiću koristite javni Wi-Fi bez lozinke, nekome je prilično lako ponašati se poput vašeg usmjerivača, tako da svi zahtjevi i odgovori prolaze kroz njih. Ako vaši podaci nisu šifrirani, tada s njima mogu raditi što god žele. Oni mogu uređivati ​​HTML, CSS ili JavaScript prije nego što uopće stigne u vaš preglednik. S obzirom na ono što znamo o XSS-u, možete zamisliti koliko bi to moglo biti loše.

Ok, ali kako to da moje računalo i poslužitelj znaju kako šifrirati / dešifrirati, ali ovaj MITM ne?

Tu dolazi SSL (Secure Sockets Layer), a od nedavno i TLS (Transport Layer Security). TLS je 1999. godine preuzeo SSL kao tehnologiju šifriranja koja se koristi u HTTPS-u. Točno kako TLS funkcionira izvan je dosega ovog posta.

HTTP stroga sigurnost prijenosa (HSTS)

Ovaj je prilično jednostavan. Koristimo zaglavlje Facebooka kao primjer:

strict-transport-security: max-age=15552000; preload
  • max-age određuje koliko dugo preglednik treba imati na umu da prisili korisnika da pristupi web mjestu pomoću HTTPS-a.
  • preloadnije važno za naše svrhe. To je usluga koju hostira Google i nije dio specifikacije HSTS.

Ovo se zaglavlje odnosi samo ako ste web mjestu pristupili pomoću HTTPS-a. Ako ste web mjestu pristupili putem HTTP-a, zaglavlje se zanemaruje. Razlog je taj što je, jednostavno, HTTP toliko nesiguran da mu se ne može vjerovati.

Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, //facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, //facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.

Closing Thoughts

Web security is important no matter where you are in your web development journey. The more you expose yourself to it, the better off you will be. Security is something that should be important to everyone, not just the people who have it explicitly named in their job title! ?