Kiire sissejuhatus veebiturvalisusse

Veebiarendaja aabits CORS-il, CSP-l, HSTS-il ja kõigil veebiturvalisuse akronüümidel!

Veebiturbe tundmaõppimiseks on palju põhjuseid, näiteks:

  • Olete mures kasutaja, kes on mures teie isikuandmete lekkimise pärast
  • Olete mures veebiarendaja, kes soovib oma veebirakendusi turvalisemaks muuta
  • Olete veebiarendaja, kes kandideerib töökohtadele ja soovite olla valmis, kui intervjueerijad esitavad teile veebiturbe kohta küsimusi

ja nii edasi.

Noh, see postitus selgitab mõningaid levinud veebiturvalisuse akronüüme viisil, mis on hõlpsasti mõistetav, kuid siiski täpne.

Enne kui seda teeme, veenduge, et mõistaksime paari turvalisuse põhimõistet.

Kaks peamist turvakontseptsiooni

Keegi pole kunagi 100% ohutu.

Pole mõtet olla 100% kaitstud häkkimise eest. Kui keegi sulle seda kunagi ütleb, siis ta eksib.

Ühest kaitsekihist ei piisa.

Sa ei saa lihtsalt öelda ...

Oh, kuna mul on CSP rakendatud, olen ma turvaline. Võin saididevahelise skriptimise oma haavatavuste loendist välja jätta, sest seda ei saa praegu juhtuda.

Võib-olla on see mõnele antud, kuid on lihtne leida end selliselt mõtlemas. Ma arvan, et üks põhjus, miks programmeerijad võivad end niimoodi mõtlema sattuda, on see, et nii suur osa kodeerimisest on mustvalge, 0 või 1, tõene või vale. Turvalisus pole nii lihtne.

Alustame ühega, millega igaüks satub oma veebiarenduse teekonna alguses üsna varakult. Ja siis vaatate StackOverflow lehte ja leiate hulga vastuseid, mis ütlevad teile, kuidas sellest mööda minna.

Päritoluülene ressursside jagamine (CORS)

Kas olete kunagi saanud vea, mis nägi välja umbes selline?

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

Te pole kindlasti üksi. Ja siis googeldate seda ja keegi ütleb teile, et hankige see laiendus, mis kõik probleemid kaob!

Suurepärane, eks?

CORS on selleks, et teid kaitsta, mitte haiget teha!

Selgitamaks, kuidas CORS teid aitab, räägime kõigepealt küpsistest, täpsemalt autentimisküpsistest . Autentimisküpsiseid kasutatakse serverile teatamiseks, et olete sisse logitud, ja need saadetakse automaatselt koos kõigi teie sellele serverile tehtud taotlustega.

Oletame, et olete Facebooki sisse logitud ja nad kasutavad autentimisküpsiseid. Klõpsate sellel, bit.ly/r43nugikuhu teid suunatakse superevilwebsite.rocks. Sisemine skript superevilwebsite.rocksesitab kliendipoolse päringu, facebook.commillele saadetakse teie autentimisküpsis!

CORS-i keelatud maailmas võivad nad teie kontol muudatusi teha, ilma et te sellest isegi teaksite. Kuni nad muidugi postitavad bit.ly/r43nugiteie ajaskaalale ja kõik teie sõbrad klõpsavad seda ning seejärel postitavad bit.ly/r43nugikõik teie sõprade ajaskaalad ja siis jätkub tsükkel kurja laiusega esimene skeem, mis vallutab kõik Facebooki kasutajad, ja maailma tarbib superevilwebsite.rocks. ?

CORS-maailmas lubab Facebook facebook.comoma serveris andmeid redigeerida aga ainult päringutega, mille päritolu on . Teisisõnu piiraksid need päritoluüleste ressursside jagamist. Seejärel võite küsida…

Kas superevilwebsite.rocks saab nende päringu korral lihtsalt muuta päise päist, nii et tundub, et see pärineb facebook.com-ist?

Nad võivad proovida, kuid see ei toimi, sest brauser lihtsalt ignoreerib seda ja kasutab tegelikku päritolu.

Ok, aga mis siis, kui superevilwebsite.rocks tegi päringu serveripoolseks?

Sel juhul võivad nad mööda minna CORS-ist, kuid nad ei võida, sest nad ei saa sõidu ajaks teie autentimisküpsist saata. Skript peaks kliendipoolsetele küpsistele juurdepääsu saamiseks olema käivitatud kliendipoolel.

Sisu turbepoliitika (CSP)

CSP mõistmiseks peame kõigepealt rääkima ühest levinumast haavatavusest veebis: XSS, mis tähistab saididevahelist skriptimist (yay - teine ​​lühend).

XSS on see, kui mõni kuri inimene süstib JavaScripti teie kliendipoolsesse koodi. Võib ju mõelda ...

Mida nad teevad? Kas muuta värvi punasest siniseks?

Oletame, et keegi on teie külastatava veebisaidi kliendipoolsesse koodi edukalt sisestanud JavaScripti.

Mida nad saaksid teha, mis oleks pahatahtlik?

  • Nad võivad esitada HTTP-päringuid teisele saidile, teeseldes, et olete teie.
  • Nad võiksid lisada ankrumärgendi, mis saadab teid veebisaidile, mis näeb välja identne teie külastatava veebisaidiga ja millel on veidi erinevad pahatahtlikud omadused.
  • Nad said lisada tekstisisese JavaScripti skriptimärgendi.
  • Nad võiksid lisada skripti märgendi, mis tõmbab kusagilt JavaScripti kaugfaili.
  • Nad võivad lisada iframe'i, mis katab lehe ja näeb välja nagu osa veebisaidist, mis palub teil parooli sisestada.

Võimalusi on lõputult.

CSP püüab seda vältida, piirates järgmist:

  • mida saab iframe'is avada
  • milliseid stiililehti saab laadida
  • kus saab taotlusi esitada jne.

Kuidas see siis töötab?

Kui klõpsate lingil või tippite oma brauseri aadressiribale veebisaidi URL-i, esitab teie brauser GET-päringu. Lõpuks jõuab ta serverisse, mis serveerib HTML-i koos mõne HTTP-päisega. Kui soovite teada, milliseid päiseid saate, avage oma konsoolis vahekaart Võrk ja külastage mõnda veebisaiti.

Võite näha vastuse päist, mis näeb välja selline:

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;

See on ettevõtte sisuturbe poliitika facebook.com. Vormindame selle ümber, et oleks hõlpsam lugeda:

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;

Lammutame nüüd direktiivid.

  • default-src piirab kõiki muid CSP direktiive, mida pole otseselt loetletud.
  • script-srcpiirab laaditavaid skripte.
  • style-src piirab laaditavaid stiililehti.
  • connect-src piirab URL-e, mida saab skripti liideste abil laadida, nii et tõmmake, XHR, ajax jne.

Pange tähele, et CSP direktiive on palju rohkem kui ainult need neli, mis on eespool näidatud. Brauser loeb CSP päist ja rakendab need direktiivid kõigele HTML-failis, mida esitati. Kui direktiivid on asjakohaselt kehtestatud, lubavad need ainult vajalikku.

Kui CSP päist pole, siis kõik läheb ja midagi pole piiratud. Kõikjal *, kus näete , on see metamärk. Võite ette kujutada, et asendate *millegagi ja see on lubatud.

HTTPS või HTTP turvaline

Kindlasti olete kuulnud HTTPS-ist. Võib-olla olete kuulnud mõnda inimest ütlemas ...

Miks ma hoolin HTTPS-i kasutamisest, kui ma olen lihtsalt mõnda mängu mängival veebisaidil?

Või äkki olete kuulnud teist poolt ...

Olete hull, kui teie saidil pole HTTPS-i. On 2018! Ära usalda kedagi, kes ütleb teisiti.

Võib-olla olete kuulnud, et Chrome märgib nüüd teie saidi ebaturvaliseks, kui see pole HTTPS.

Põhimõtteliselt on HTTPS üsna sirgjooneline. HTTPS on krüptitud ja HTTP mitte.

Miks see siis on oluline, kui te ei saada tundlikke andmeid?

Valmistuge veel üheks lühendiks ... MITM, mis tähistab inimest keset.

Kui kasutate kohvikus paroolita avalikku WiFi-d, on kellelgi üsna lihtne käituda nagu teie ruuter, nii et kõik taotlused ja vastused lähevad neist läbi. Kui teie andmed pole krüpteeritud, saavad nad sellega teha kõike, mida nad tahavad. Nad saavad muuta HTML-i, CSS-i või JavaScripti, enne kui see teie brauserisse jõuab. Arvestades seda, mida me XSS-ist teame, võite ette kujutada, kui halb see võib olla.

Ok, aga kuidas on nii, et minu arvuti ja server teavad, kuidas krüpteerida / dekrüpteerida, aga see MITM seda ei tee?

That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.

HTTP Strict-Transport-Security (HSTS)

This one is pretty straightforward. Let’s use Facebook’s header as an example again:

strict-transport-security: max-age=15552000; preload
  • max-age specifies how long a browser should remember to force the user to access a website using HTTPS.
  • preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.

This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.

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

Veebiturvalisus on oluline olenemata sellest, kus te oma veebiarenduse teekonnal olete. Mida rohkem end sellele eksponeerite, seda parem on teil. Turvalisus peaks olema oluline kõigile, mitte ainult inimestele, kellel on see ametinimetuses sõnaselgelt nimetatud! ?