Tīmekļa drošības galvenes: Satura drošības politika (CSP) pret JavaScript izpildi

Pastāvīgi mainīgajā tīmekļa drošības vidē ir ļoti svarīgi aizsargāt jūsu tīmekļa lietojumprogrammas pret tādām ievainojamībām kā starpvietņu skriptošanas (XSS) uzbrukumi. Divi spēcīgi rīki jūsu arsenālā ir Satura drošības politika (CSP) un rūpīga izpratne par to, kā pārlūkprogrammā tiek izpildīts JavaScript. Šajā emuāra ierakstā tiks detalizēti aplūkotas CSP nianses, izpētīta tās saistība ar JavaScript izpildi un sniegti praktiski ieteikumi izstrādātājiem un drošības profesionāļiem visā pasaulē.

Izpratne par Satura drošības politiku (CSP)

Satura drošības politika (CSP) ir spēcīgs drošības standarts, kas palīdz mazināt starpvietņu skriptošanas (XSS) un citus koda ievadīšanas uzbrukumus. Tā darbojas, ļaujot jums kontrolēt resursus, kurus pārlūkprogrammai ir atļauts ielādēt konkrētai tīmekļa lapai. Uztveriet to kā savas vietnes satura balto sarakstu. Definējot CSP, jūs būtībā paziņojat pārlūkprogrammai, kuri satura avoti (skripti, stili, attēli, fonti utt.) tiek uzskatīti par drošiem un no kurienes tie var nākt. Tas tiek panākts, izmantojot HTTP atbildes galvenes.

Kā darbojas CSP

CSP tiek ieviesta, izmantojot HTTP atbildes galveni ar nosaukumu Content-Security-Policy. Šī galvene satur direktīvu kopu, kas nosaka, kuri avoti ir atļauti. Šeit ir dažas galvenās direktīvas un to funkcionalitāte:

• default-src: Šī ir rezerves direktīva visām pārējām ielādes direktīvām. Ja nav norādīta konkrētāka direktīva, default-src nosaka atļautos avotus. Piemēram, default-src 'self'; atļauj resursus no tās pašas izcelsmes.
• script-src: Definē atļautos avotus JavaScript kodam. Šī, iespējams, ir vissvarīgākā direktīva, jo tā tieši ietekmē to, kā tiek kontrolēta JavaScript izpilde.
• style-src: Norāda atļautos avotus CSS stila lapām.
• img-src: Kontrolē atļautos avotus attēliem.
• font-src: Definē atļautos avotus fontiem.
• connect-src: Norāda atļautos avotus savienojumiem (piemēram, XMLHttpRequest, fetch, WebSocket).
• media-src: Definē atļautos avotus audio un video.
• object-src: Norāda atļautos avotus spraudņiem, piemēram, Flash.
• frame-src: Definē atļautos avotus rāmjiem un iframe (novecojusi, izmantojiet child-src).
• child-src: Norāda atļautos avotus tīmekļa darbiniekiem (web workers) un iegultam rāmja saturam.
• base-uri: Ierobežo URL, ko var izmantot dokumenta <base> elementā.
• form-action: Norāda derīgus galapunktus veidlapu iesniegšanai.
• frame-ancestors: Norāda derīgos vecākelementus, kuros lapu var iegult (piemēram, <frame> vai <iframe>).

Katrai direktīvai var piešķirt avota izteiksmju kopu. Biežāk sastopamās avota izteiksmes ietver:

• 'self': Atļauj resursus no tās pašas izcelsmes (shēma, resursdators un ports).
• 'none': Bloķē visus resursus.
• 'unsafe-inline': Atļauj iekļauto JavaScript un CSS. No tā parasti ir ieteicams izvairīties, kad vien iespējams. Tas ievērojami vājina CSP piedāvāto aizsardzību.
• 'unsafe-eval': Atļauj izmantot funkcijas, piemēram, eval(), kuras bieži tiek izmantotas XSS uzbrukumos. Arī ļoti nevēlami.
• data:: Atļauj datu URL (piemēram, base64 kodētus attēlus).
• blob:: Atļauj resursus ar blob: shēmu.
• https://example.com: Atļauj resursus no norādītā domēna, izmantojot HTTPS. Jūs varat arī norādīt konkrētu ceļu, piemēram, https://example.com/assets/.
• *.example.com: Atļauj resursus no jebkura example.com apakšdomēna.

CSP galveņu piemēri:

Šeit ir daži piemēri, lai ilustrētu, kā tiek izmantotas CSP galvenes:

1. piemērs: JavaScript ierobežošana līdz tai pašai izcelsmei

            Content-Security-Policy: script-src 'self';
            

              
                Copy
              
            
          

Šī politika atļauj pārlūkprogrammai izpildīt JavaScript tikai no tās pašas izcelsmes kā lapa. Tas efektīvi novērš jebkura JavaScript, kas ievadīts no ārējiem avotiem, izpildi. Tas ir labs sākumpunkts daudzām vietnēm.

2. piemērs: JavaScript atļaušana no tās pašas izcelsmes un noteikta CDN

            Content-Security-Policy: script-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

Šī politika atļauj JavaScript no tās pašas izcelsmes un no domēna cdn.example.com. Tas ir izplatīts vietnēm, kas izmanto CDN (satura piegādes tīklu), lai apkalpotu savus JavaScript failus.

3. piemērs: Stila lapu ierobežošana līdz tai pašai izcelsmei un noteiktam CDN

            Content-Security-Policy: style-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

Šī politika ierobežo CSS ielādi līdz izcelsmei un cdn.example.com, novēršot ļaunprātīgu stila lapu ielādi no citiem avotiem.

4. piemērs: Visaptverošāka politika

            Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' fonts.googleapis.com; img-src 'self' data:; font-src fonts.gstatic.com;
            

              
                Copy
              
            
          

Šis ir sarežģītāks piemērs, kas atļauj saturu no tās pašas izcelsmes, JavaScript no tās pašas izcelsmes un CDN, CSS no tās pašas izcelsmes un Google Fonts, attēlus no tās pašas izcelsmes un datu URL, kā arī fontus no Google Fonts. Ņemiet vērā, ka jums ir skaidri jāatļauj ārējie resursi, ja jūsu vietne tos izmanto.

CSP piemērošana

CSP var piemērot divos galvenajos veidos:

• Tikai ziņošanas režīms: Jūs varat iestatīt Content-Security-Policy-Report-Only galveni. Šī galvene nebloķē nekādus resursus, bet tā vietā ziņo par pārkāpumiem uz norādīto galapunktu (piemēram, serveri, kuru jūs kontrolējat). Tas ir noderīgi, lai pārbaudītu CSP politiku pirms tās piemērošanas, ļaujot jums identificēt iespējamās problēmas un izvairīties no vietnes darbības traucējumiem. Pārlūkprogramma joprojām mēģina ielādēt resursus, bet izstrādātāja konsolē parāda brīdinājumu un nosūta ziņojumu uz jūsu norādīto galapunktu. Ziņojumā ir ietverta informācija par pārkāpumu, piemēram, bloķētā resursa avots un pārkāpjošā direktīva.
• Piespiedu režīms: Kad izmantojat Content-Security-Policy galveni, pārlūkprogramma aktīvi piemēro politiku. Ja resurss pārkāpj politiku (piemēram, skripts tiek ielādēts no neatļauta avota), pārlūkprogramma to bloķēs. Tas ir paredzētais un visefektīvākais veids, kā izmantot CSP drošībai.

JavaScript izpilde un CSP

Mijiedarbība starp CSP un JavaScript izpildi ir kritiska. CSP direktīva script-src ir galvenais kontroles punkts tam, kā tiek apstrādāts JavaScript. Kad pārlūkprogramma saskaras ar JavaScript, tā pārbauda CSP galvenes direktīvu script-src. Ja JavaScript avots ir atļauts, pārlūkprogramma to izpilda. Ja avots nav atļauts, skripts tiek bloķēts, un, ja ir iespējota ziņošana, tiek ģenerēts pārkāpuma ziņojums.

Ietekme uz JavaScript izpildi

CSP būtiski ietekmē to, kā jūs rakstāt un strukturējat savu JavaScript kodu. Konkrēti, tas var ietekmēt:

• Iekļautais JavaScript: JavaScript, kas rakstīts tieši <script> tagos jūsu HTML, bieži tiek ierobežots. Izmantojot 'unsafe-inline' direktīvā script-src, šis ierobežojums tiek mīkstināts, taču tas ir ļoti nevēlami. Labāka pieeja ir pārvietot iekļauto JavaScript uz ārējiem JavaScript failiem.
• eval() un cita dinamiskā koda izpilde: Funkcijas, piemēram, eval(), setTimeout() ar virknes argumentu un new Function() bieži tiek ierobežotas. Ir pieejama avota izteiksme 'unsafe-eval', taču no tās vajadzētu izvairīties. Tā vietā pārveidojiet savu kodu, lai izvairītos no šīm praksēm, vai izmantojiet alternatīvas metodes.
• Ārējie JavaScript faili: CSP kontrolē, kurus ārējos JavaScript failus var ielādēt. Tā ir galvenā aizsardzība pret XSS uzbrukumiem, kas mēģina ievadīt ļaunprātīgus skriptus.
• Notikumu apstrādātāji: Iekļautie notikumu apstrādātāji (piemēram, <button onclick="myFunction()"></button>) bieži tiek bloķēti, ja nav atļauts 'unsafe-inline'. Labāka prakse ir pievienot notikumu klausītājus JavaScript failos.

Labākās prakses JavaScript izpildei ar CSP

Lai efektīvi izmantotu CSP un nodrošinātu JavaScript izpildes drošību, apsveriet šīs labākās prakses:

• Izvairieties no iekļautā JavaScript: Pārvietojiet visu JavaScript kodu uz ārējiem .js failiem. Šī ir viena no ietekmīgākajām darbībām, ko varat veikt.
• Izvairieties no eval() un citas dinamiskās koda izpildes: Pārveidojiet savu kodu, lai neizmantotu eval(), setTimeout() ar virknes argumentiem un new Function(). Tie ir izplatīti uzbrukumu vektori.
• Izmantojiet "nonces" vai jaucējkodus iekļautajiem skriptiem (ja nepieciešams): Ja jums absolūti nepieciešams izmantot iekļautos skriptus (piemēram, mantotam kodam), apsveriet iespēju izmantot "nonce" (unikālu, nejauši ģenerētu virkni) vai jaucējkodu (skripta satura kriptogrāfisku jaucējvērtību). Jūs pievienojat "nonce" vai jaucējkodu savai CSP galvenei un skripta tagam. Tas ļauj pārlūkprogrammai izpildīt skriptu, ja tas atbilst norādītajiem kritērijiem. Šī ir drošāka alternatīva nekā 'unsafe-inline', bet tā palielina sarežģītību.
• Izmantojiet stingru CSP politiku: Sāciet ar ierobežojošu CSP politiku (piemēram, script-src 'self';) un pakāpeniski to mīkstiniet pēc nepieciešamības. Pirms politikas piemērošanas uzraugiet pārkāpumus, izmantojot Content-Security-Policy-Report-Only galveni.
• Regulāri pārskatiet un atjauniniet savu CSP politiku: Jūsu tīmekļa lietojumprogramma laika gaitā attīstīsies, tāpat kā jūsu CSP politika. Regulāri pārskatiet un atjauniniet savu politiku, lai nodrošinātu, ka tā joprojām sniedz adekvātu aizsardzību. Tas ietver jaunu funkciju pievienošanu, trešo pušu bibliotēku integrēšanu vai CDN konfigurācijas maiņu.
• Izmantojiet tīmekļa lietojumprogrammu ugunsmūri (WAF): WAF var palīdzēt atklāt un mazināt uzbrukumus, kas varētu apiet jūsu CSP. WAF darbojas kā papildu aizsardzības slānis.
• Apsveriet drošību jau projektēšanas posmā: Ieviesiet drošības principus jau no paša projekta sākuma, ieskaitot drošas kodēšanas prakses un regulārus drošības auditus.

CSP darbībā: reālās pasaules piemēri

Apskatīsim dažus reālās pasaules scenārijus un to, kā CSP palīdz mazināt ievainojamības:

1. scenārijs: XSS uzbrukumu novēršana no ārējiem avotiem

Vietne ļauj lietotājiem iesniegt komentārus. Uzbrucējs komentārā ievada ļaunprātīgu JavaScript. Bez CSP pārlūkprogramma izpildītu ievadīto skriptu. Ar CSP, kas atļauj skriptus tikai no tās pašas izcelsmes (script-src 'self';), pārlūkprogramma bloķēs ļaunprātīgo skriptu, jo tas nāk no cita avota.

2. scenārijs: XSS uzbrukumu novēršana no uzticama, bet kompromitēta CDN

Vietne izmanto CDN (satura piegādes tīklu), lai apkalpotu savus JavaScript failus. Uzbrucējs kompromitē CDN un aizstāj likumīgos JavaScript failus ar ļaunprātīgiem. Ar CSP, kas norāda CDN domēnu (piemēram, script-src 'self' cdn.example.com;), vietne ir aizsargāta, jo tā ierobežo izpildi tikai ar failiem, kas mitināti konkrētajā CDN domēnā. Ja kompromitētais CDN izmanto citu domēnu, pārlūkprogramma bloķētu ļaunprātīgos skriptus.

3. scenārijs: Riska mazināšana ar trešo pušu bibliotēkām

Vietne integrē trešās puses JavaScript bibliotēku. Ja šī bibliotēka tiek kompromitēta, uzbrucējs var ievadīt ļaunprātīgu kodu. Izmantojot stingru CSP, izstrādātāji var ierobežot JavaScript izpildi no trešās puses bibliotēkas, norādot avota direktīvas savā CSP politikā. Piemēram, norādot konkrētas trešās puses bibliotēkas izcelsmes, vietne var pasargāt sevi no potenciāliem ekspluatācijas gadījumiem. Tas ir īpaši svarīgi atvērtā pirmkoda bibliotēkām, kuras bieži tiek izmantotas daudzos projektos visā pasaulē.

Globālie piemēri:

Apsveriet daudzveidīgo pasaules digitālo ainavu. Tādās valstīs kā Indija, ar to lielo iedzīvotāju skaitu un plašo interneta piekļuvi, bieži saskaras ar unikāliem drošības izaicinājumiem pieaugošā pievienoto ierīču skaita dēļ. Līdzīgi Eiropas reģionos, kur ir stingra GDPR (Vispārīgā datu aizsardzības regula) atbilstība, droša tīmekļa lietojumprogrammu izstrāde ir vissvarīgākā. CSP izmantošana un drošu JavaScript prakšu pielietošana var palīdzēt organizācijām visos šajos reģionos izpildīt savas drošības atbilstības saistības. Tādās valstīs kā Brazīlija, kur e-komercija strauji aug, tiešsaistes darījumu nodrošināšana ar CSP ir būtiska, lai aizsargātu gan uzņēmumu, gan patērētāju. Tas pats attiecas uz Nigēriju, Indonēziju un katru nāciju.

Papildu CSP tehnikas

Papildus pamatiem, vairākas papildu tehnikas var uzlabot jūsu CSP ieviešanu:

• Uz "nonce" balstīta CSP: Strādājot ar iekļautajiem skriptiem, "nonces" nodrošina drošāku alternatīvu 'unsafe-inline'. "Nonce" ir unikāla, nejauši ģenerēta virkne, ko jūs ģenerējat katram pieprasījumam un iekļaujat gan savā CSP galvenē (script-src 'nonce-JŪSU_NONCE';), gan <script> tagā (<script nonce="JŪSU_NONCE">). Tas norāda pārlūkprogrammai izpildīt tikai tos skriptus, kuriem ir atbilstošs "nonce". Šī pieeja ievērojami ierobežo uzbrucēju iespējas ievadīt ļaunprātīgu kodu.
• Uz jaucējkodu balstīta CSP (SRI - apakšresursu integritāte): Tas ļauj jums norādīt skripta satura kriptogrāfisko jaucējkodu (piemēram, izmantojot SHA-256 algoritmu). Pārlūkprogramma izpildīs skriptu tikai tad, ja tā jaucējkods atbilst tam, kas norādīts CSP galvenē. Šis ir vēl viens veids, kā apstrādāt iekļautos skriptus (retāk) vai ārējos skriptus. Apakšresursu integritāte parasti tiek izmantota ārējiem resursiem, piemēram, CSS un JavaScript bibliotēkām, un tā aizsargā pret risku, ka kompromitēts CDN apkalpo ļaunprātīgu kodu, kas atšķiras no paredzētās bibliotēkas.
• CSP ziņošanas API: CSP ziņošanas API ļauj apkopot detalizētu informāciju par CSP pārkāpumiem, ieskaitot pārkāpjošo direktīvu, bloķētā resursa avotu un lapas URL, kurā noticis pārkāpums. Šī informācija ir būtiska, lai uzraudzītu, novērstu problēmas un uzlabotu jūsu CSP politiku. Vairāki rīki un pakalpojumi var palīdzēt jums apstrādāt šos ziņojumus.
• CSP veidošanas rīki: Rīki var palīdzēt jums ģenerēt un pārbaudīt CSP politikas, piemēram, CSP Evaluator un tiešsaistes CSP veidotāji. Tie var racionalizēt jūsu politiku izveides un pārvaldības procesu.

JavaScript izpildes un drošības labākās prakses

Papildus CSP, apsveriet šādas vispārīgas drošības labākās prakses attiecībā uz JavaScript:

• Ievades validācija un sanitizācija: Vienmēr validējiet un sanitizējiet lietotāja ievadi gan servera, gan klienta pusē, lai novērstu XSS un citus ievadīšanas uzbrukumus. Sanitizējiet datus, lai noņemtu vai kodētu potenciāli bīstamas rakstzīmes, piemēram, tās, kas tiek izmantotas skripta iniciēšanai.
• Drošas kodēšanas prakses: Ievērojiet drošas kodēšanas principus, piemēram, izmantojiet parametrizētus vaicājumus, lai novērstu SQL injekcijas, un izvairieties no sensitīvu datu glabāšanas klienta puses kodā. Esiet uzmanīgi, kā kods apstrādā potenciāli sensitīvus datus.
• Regulāri drošības auditi: Veiciet regulārus drošības auditus, ieskaitot iespiešanās testēšanu, lai identificētu un novērstu ievainojamības jūsu tīmekļa lietojumprogrammās. Drošības audits, pazīstams arī kā iespiešanās tests, ir simulēts uzbrukums sistēmai. Šie auditi ir būtiski, lai atklātu ievainojamības, kuras uzbrucēji var izmantot.
• Atjauniniet atkarības: Regulāri atjauniniet savas JavaScript bibliotēkas un ietvarus uz jaunākajām versijām, lai labotu zināmās ievainojamības. Ievainojamas bibliotēkas ir galvenais drošības problēmu avots. Izmantojiet atkarību pārvaldības rīkus, lai automatizētu atjauninājumus.
• Ieviesiet HTTP Strict Transport Security (HSTS): Nodrošiniet, ka jūsu tīmekļa lietojumprogramma izmanto HTTPS un ievieš HSTS, lai piespiestu pārlūkprogrammas vienmēr pieslēgties jūsu vietnei, izmantojot HTTPS. Tas palīdz novērst "man-in-the-middle" uzbrukumus.
• Izmantojiet tīmekļa lietojumprogrammu ugunsmūri (WAF): WAF pievieno papildu drošības slāni, filtrējot ļaunprātīgu datplūsmu un novēršot uzbrukumus, kas apiet citus drošības pasākumus. WAF var atklāt un mazināt ļaunprātīgus pieprasījumus, piemēram, SQL injekcijas vai XSS mēģinājumus.
• Izglītojiet savu izstrādes komandu: Nodrošiniet, ka jūsu izstrādes komanda izprot tīmekļa drošības labākās prakses, ieskaitot CSP, XSS novēršanu un drošas kodēšanas principus. Jūsu komandas apmācība ir kritisks ieguldījums drošībā.
• Uzraugiet drošības apdraudējumus: Iestatiet uzraudzības un brīdināšanas sistēmas, lai ātri atklātu un reaģētu uz drošības incidentiem. Efektīva uzraudzība palīdz identificēt un reaģēt uz potenciāliem drošības apdraudējumiem.

Visu saliekot kopā: praktisks ceļvedis

Izveidosim vienkāršotu piemēru, lai ilustrētu, kā pielietot šos jēdzienus.

Scenārijs: Vienkārša vietne ar kontaktu veidlapu, kas izmanto JavaScript, lai apstrādātu veidlapas iesniegšanu.

1. 1. solis: Analizējiet lietojumprogrammas atkarības: Nosakiet visus JavaScript failus, ārējos resursus (piemēram, CDN) un iekļautos skriptus, ko izmanto jūsu lietojumprogramma. Identificējiet visus skriptus, kas nepieciešami pareizai funkcionalitātei.
2. 2. solis: Pārvietojiet JavaScript uz ārējiem failiem: Pārvietojiet jebkuru iekļauto JavaScript uz atsevišķiem .js failiem. Tas ir fundamentāli.
3. 3. solis: Definējiet pamata CSP galveni: Sāciet ar ierobežojošu CSP. Piemēram, ja izmantojat to pašu izcelsmi, jūs varētu sākt ar šādu:

               Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;
               
   
                 
                   Copy
                 
               
             

4. 4. solis: Pārbaudiet CSP tikai ziņošanas režīmā: Sākotnēji ieviesiet Content-Security-Policy-Report-Only galveni, lai identificētu jebkādus potenciālos konfliktus. Apkopojiet ziņojumus un analizējiet tos.
5. 5. solis: Novērsiet visus pārkāpumus: Pamatojoties uz ziņojumiem, pielāgojiet CSP galveni, lai atļautu nepieciešamos resursus. Tas var ietvert konkrētu CDN domēnu iekļaušanu baltajā sarakstā vai, ja absolūti nepieciešams, "nonces" vai jaucējkodu izmantošanu iekļautajiem skriptiem (lai gan tas reti ir nepieciešams, ja tiek ievērotas labākās prakses).
6. 6. solis: Ieviesiet un uzraugiet: Kad esat pārliecināts, ka CSP darbojas pareizi, pārslēdzieties uz Content-Security-Policy galveni. Nepārtraukti uzraugiet savu lietojumprogrammu attiecībā uz pārkāpumiem un pēc nepieciešamības pielāgojiet savu CSP politiku.
7. 7. solis: Ieviesiet ievades validāciju un sanitizāciju: Nodrošiniet, ka servera un klienta puses kods validē un sanitizē lietotāja ievadi, lai novērstu ievainojamības. Tas ir kritiski svarīgi, lai aizsargātos pret XSS uzbrukumiem.
8. 8. solis: Regulāri auditi un atjauninājumi: Regulāri pārskatiet un atjauniniet savu CSP politiku, paturot prātā jaunas funkcijas, integrācijas un jebkādas izmaiņas lietojumprogrammas arhitektūrā vai atkarībās. Ieviesiet regulārus drošības auditus, lai atklātu neparedzētas problēmas.

Secinājums

Satura drošības politika (CSP) ir būtiska mūsdienu tīmekļa drošības sastāvdaļa, kas darbojas kopā ar JavaScript izpildes praksēm, lai aizsargātu jūsu tīmekļa lietojumprogrammas no plaša apdraudējumu klāsta. Izprotot, kā CSP direktīvas kontrolē JavaScript izpildi, un ievērojot drošības labākās prakses, jūs varat ievērojami samazināt XSS uzbrukumu risku un uzlabot savu tīmekļa lietojumprogrammu vispārējo drošību. Atcerieties pieņemt slāņveida pieeju drošībai, integrējot CSP ar citiem drošības pasākumiem, piemēram, ievades validāciju, tīmekļa lietojumprogrammu ugunsmūriem (WAF) un regulāriem drošības auditiem. Konsekventi piemērojot šos principus, jūs varat radīt drošāku tīmekļa pieredzi saviem lietotājiem neatkarīgi no viņu atrašanās vietas vai izmantotās tehnoloģijas. Jūsu tīmekļa lietojumprogrammu nodrošināšana ne tikai aizsargā jūsu datus, bet arī veido uzticību jūsu globālajai auditorijai un veido uzticamības un drošības reputāciju.