Ātrs ievads tīmekļa drošībā

Tīmekļa izstrādātāja primer par CORS, CSP, HSTS un visiem tīmekļa drošības akronīmiem!

Ir daudz iemeslu, lai uzzinātu par tīmekļa drošību, piemēram:

  • Jūs esat noraizējies lietotājs, kurš uztraucas par jūsu personas datu noplūdi
  • Jūs esat noraizējies tīmekļa izstrādātājs, kurš vēlas padarīt savas tīmekļa lietotnes drošākas
  • Jūs esat tīmekļa izstrādātājs, kurš piesakās darbam, un vēlaties būt gatavs, ja intervētāji jums uzdos jautājumus par tīmekļa drošību

un tā tālāk.

Labi, ka šis ieraksts paskaidros dažus izplatītākos tīmekļa drošības akronīmus viegli saprotamā, bet tomēr precīzā veidā.

Pirms to izdarīsim, pārliecinieties, ka saprotam pāris drošības pamatjēdzienus.

Divi drošības pamatjēdzieni

Neviens nekad nav 100% drošībā.

Nav jēgas būt 100% aizsargātam pret uzlaušanu. Ja kāds jums kādreiz to saka, viņš kļūdās.

Nepietiek ar vienu aizsardzības slāni.

Jūs nevarat vienkārši pateikt ...

Ak, tāpēc, ka man ir ieviests SPS, es esmu drošībā. Varu svītrot vairāku vietņu skriptu izveidi no sava ievainojamību saraksta, jo tas tagad nevar notikt.

Varbūt tas ir dots dažiem, bet ir viegli atrast sev domu šādā veidā. Es domāju, ka viens iemesls, kāpēc programmētāji var viegli atrast domu šādā veidā, ir tāpēc, ka tik daudz kodēšanas ir melnbalts, 0 vai 1, patiess vai nepatiess. Drošība nav tik vienkārša.

Mēs sāksim ar tādu, ar kuru visi saskaras diezgan agri savā tīmekļa izstrādes ceļojumā. Un tad jūs paskatāties uz StackOverflow un atrodat virkni atbilžu, kas stāsta, kā to apiet.

Resursu kopīga izmantošana (CORS)

Vai esat kādreiz saņēmis kļūdu, kas izskatījās apmēram tā?

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

Jūs noteikti neesat viens. Un pēc tam jūs to meklējat Google tīklā, un kāds jums saka iegūt šo paplašinājumu, kas ļaus jums izzust visas problēmas!

Lieliski, vai ne?

CORS ir tāpēc, lai jūs aizsargātu, nevis sāpinātu!

Lai izskaidrotu, kā CORS jums palīdz, vispirms runāsim par sīkdatnēm, īpaši par autentifikācijas sīkdatnēm . Autentifikācijas sīkfaili tiek izmantoti, lai paziņotu serverim, ka esat pieteicies, un tie tiek automātiski nosūtīti kopā ar visiem pieprasījumiem, ko veicat šim serverim.

Pieņemsim, ka esat pieteicies Facebook, un viņi izmanto autentifikācijas sīkfailus. Jūs noklikšķināt uz bit.ly/r43nugikura jūs novirza superevilwebsite.rocks. Iekšējais skripts superevilwebsite.rocksveic klienta puses pieprasījumu, uz facebook.comkuru tiek nosūtīts jūsu autentifikācijas sīkfails!

Pasaulē bez CORS viņi varēja veikt izmaiņas jūsu kontā, jūs pat nezināt. Līdz, protams, līdz viņi izliek bit.ly/r43nugijūsu laika skalā, un visi jūsu draugi noklikšķina uz tā, un pēc tam viņi izliek bit.ly/r43nugivisus jūsu draugu laika grafikus, un pēc tam cikls turpinās ļaunuma pirmajā shēmā, kas iekaro visus Facebook lietotājus, un pasauli patērē superevilwebsite.rocks. ?

CORS pasaulē Facebook tomēr atļauj facebook.comrediģēt datus savā serverī tikai pieprasījumiem ar izcelsmi . Citiem vārdiem sakot, tie ierobežotu savstarpējas izcelsmes resursu koplietošanu. Tad jūs varētu jautāt ...

Vai superevilwebsite.rocks pēc viņu pieprasījuma var vienkārši mainīt izcelsmes galveni, lai izskatās, ka tas nāk no facebook.com?

Viņi var mēģināt, taču tas nedarbosies, jo pārlūks to vienkārši ignorēs un izmantos patieso izcelsmi.

Labi, bet ko darīt, ja superevilwebsite.rocks pieprasījumu veica servera pusē?

Šajā gadījumā viņi varētu apiet CORS, taču viņi neuzvarēs, jo nevarēs nosūtīt jūsu autentifikācijas sīkfailu braucienam. Skripts būs jāizpilda klienta pusē, lai piekļūtu jūsu klienta puses sīkdatnēm.

Satura drošības politika (CSP)

Lai saprastu CSP, mums vispirms ir jārunā par vienu no visizplatītākajām tīmekļa ievainojamībām: XSS, kas nozīmē vairāku vietņu skriptu (yay - vēl viens saīsinājums).

XSS ir gadījums, kad kāds ļauns cilvēks injicē JavaScript jūsu klienta puses kodā. Jūs varētu domāt ...

Ko viņi darīs? Mainīt krāsu no sarkanas uz zilu?

Pieņemsim, ka kāds ir veiksmīgi ievadījis JavaScript jūsu apmeklētās vietnes klienta puses kodā.

Ko viņi varētu darīt, kas būtu ļaunprātīgi?

  • Viņi varētu veikt HTTP pieprasījumus uz citu vietni, izliekoties par tevi.
  • Viņi varētu pievienot enkura tagu, kas novirza jūs uz vietni, kas izskatās identiska tai, kurā atrodaties, ar nedaudz atšķirīgām, ļaunprātīgām īpašībām.
  • Viņi varēja pievienot skripta tagu ar iekļauto JavaScript.
  • Viņi varētu pievienot skripta tagu, kas kaut kur ienes attālu JavaScript failu.
  • Viņi varētu pievienot iframe, kas aptver lapu un izskatās kā daļa no vietnes, kas mudina jūs ievietot paroli.

Iespējas ir bezgalīgas.

SPS mēģina novērst tā rašanos, ierobežojot:

  • ko var atvērt iframe
  • kādas stila lapas var ielādēt
  • kur var iesniegt pieprasījumus utt.

Tātad, kā tas darbojas?

Noklikšķinot uz saites vai pārlūkprogrammas adreses joslā ierakstot vietnes URL, pārlūkprogramma veic GET pieprasījumu. Tas galu galā nonāk pie servera, kas kopā ar dažām HTTP galvenēm apkalpo HTML. Ja vēlaties uzzināt, kādas galvenes jūs saņemat, konsolē atveriet cilni Tīkls un apmeklējiet dažas vietnes.

Iespējams, redzēsit atbildes galveni, kas izskatās šādi:

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;

Tā ir vietnes satura drošības politika facebook.com. Pārformatēsim to, lai būtu vieglāk lasīt:

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;

Tagad sadalīsim direktīvas.

  • default-src ierobežo visas citas SPS direktīvas, kas nav skaidri uzskaitītas.
  • script-srcierobežo skriptus, kurus var ielādēt.
  • style-src ierobežo stila lapas, kuras var ielādēt.
  • connect-src ierobežo vietrāžus URL, kurus var ielādēt, izmantojot skriptu saskarnes, tāpēc ielādējiet, XHR, ajax utt.

Ņemiet vērā, ka SPS direktīvu ir daudz vairāk nekā tikai šīs četras iepriekš redzamās. Pārlūkprogramma nolasīs SPS galveni un piemēros šīs direktīvas visam HTML failā, kas tika piegādāts. Ja direktīvas ir noteiktas atbilstoši, tās pieļauj tikai to, kas nepieciešams.

Ja nav CSP galvenes, tad viss notiek, un nekas nav ierobežots. Visur, kur redzat *, tā ir aizstājējzīme. Jūs varat iedomāties aizstāt *ar kaut ko, un tas būs atļauts.

HTTPS vai HTTP drošs

Jūs noteikti esat dzirdējuši par HTTPS. Varbūt esat dzirdējuši dažus cilvēkus sakām ...

Kāpēc man rūp HTTPS izmantošana, ja es atrodos tikai vietnē, kur spēlēju spēli.

Vai varbūt esat dzirdējuši otru pusi ...

Jūs esat traks, ja jūsu vietnei nav HTTPS. Ir 2018. gads! Neuzticieties nevienam, kurš saka citādi.

Varbūt jūs dzirdējāt, ka Chrome tagad atzīmēs jūsu vietni kā nedrošu, ja tā nav HTTPS.

Būtībā HTTPS ir diezgan vienkāršs. HTTPS ir šifrēts, bet HTTP nav.

Tātad, kāpēc tas ir svarīgi, ja nesūtāt sensitīvus datus?

Sagatavojieties citam saīsinājumam ... MITM, kas nozīmē Cilvēks vidū.

Ja kafejnīcā izmantojat publisko Wi-Fi bez paroles, kādam ir diezgan viegli rīkoties tāpat kā jūsu maršrutētājam, lai visi pieprasījumi un atbildes tiem tiktu cauri. Ja jūsu dati nav šifrēti, viņi ar tiem var darīt visu, ko vēlas. Viņi var rediģēt HTML, CSS vai JavaScript, pirms tie pat nonāk jūsu pārlūkprogrammā. Ņemot vērā to, ko mēs zinām par XSS, jūs varat iedomāties, cik slikti tas varētu būt.

Labi, bet kā tas notiek, ka mans dators un serveris zina, kā šifrēt / atšifrēt, bet šis MITM to nedara?

Šeit ienāk SSL (Secure Sockets Layer) un nesen TLS (Transport Layer Security). TLS 1999. gadā SSL pārņēma kā šifrēšanas tehnoloģiju, ko izmanto HTTPS. Tieši tas, kā darbojas TLS, ir ārpus šīs ziņas darbības jomas.

HTTP stingra transporta drošība (HSTS)

Šis ir diezgan vienkāršs. Vēlreiz izmantosim Facebook galveni:

strict-transport-security: max-age=15552000; preload
  • max-age norāda, cik ilgi pārlūkprogrammai jāatceras piespiest lietotāju piekļūt vietnei, izmantojot HTTPS.
  • preloadnav svarīgs mūsu mērķiem. Tas ir Google mitināts pakalpojums, kas nav daļa no HSTS specifikācijas.

Šī galvene attiecas tikai tad, ja vietnei piekļuvāt, izmantojot HTTPS. Ja vietnei piekļuvāt, izmantojot HTTP, galvene tiek ignorēta. Iemesls ir tāds, ka gluži vienkārši HTTP ir tik nedrošs, ka tam nevar uzticēties.

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

Tīmekļa drošība ir svarīga neatkarīgi no tā, kur atrodaties savā tīmekļa attīstības ceļojumā. Jo vairāk jūs tam pakļaujat, jo labāk jums klāsies. Drošība ir kaut kas svarīgs ikvienam, ne tikai cilvēkiem, kuriem tas ir skaidri norādīts amata nosaukumā! ?