Veebiturvalisuse päised: Sisuturvapoliitika (CSP) vs. JavaScripti täitmine

Pidevalt arenevas veebiturvalisuse maastikus on esmatähtis kaitsta oma veebirakendusi haavatavuste, näiteks saidiülese skriptimise (XSS) rünnakute eest. Kaks võimsat tööriista teie arsenalis on sisuturvapoliitika (CSP) ja põhjalik arusaam sellest, kuidas JavaScripti brauseris täidetakse. See blogipostitus süveneb CSP keerukustesse, uurib selle suhet JavaScripti täitmisega ja pakub praktilisi teadmisi arendajatele ja turvaspetsialistidele üle maailma.

Sisuturvapoliitika (CSP) mõistmine

Sisuturvapoliitika (CSP) on võimas turvastandard, mis aitab leevendada saidiülest skriptimist (XSS) ja muid koodi sisestamise rünnakuid. See toimib, lubades teil kontrollida ressursse, mida brauseril on lubatud antud veebilehe jaoks laadida. Mõelge sellest kui oma veebisaidi sisu valgest nimekirjast. CSP määratlemisega ütlete te brauserile sisuliselt, millised sisuallikad (skriptid, stiilid, pildid, fondid jne) on ohutud ja kust need võivad pärineda. See saavutatakse HTTP vastuse päiste abil.

Kuidas CSP töötab

CSP rakendatakse HTTP vastuse päise nimega Content-Security-Policy kaudu. See päis sisaldab direktiivide komplekti, mis dikteerivad, millised allikad on lubatud. Siin on mõned peamised direktiivid ja nende funktsioonid:

• default-src: See on tagavara direktiiv kõigi teiste päringudirektiivide jaoks. Kui spetsiifilisemat direktiivi pole antud, määrab default-src lubatud allikad. Näiteks default-src 'self'; lubab ressursse samast päritolust.
• script-src: Määratleb lubatud allikad JavaScripti koodi jaoks. See on vaieldamatult kõige kriitilisem direktiiv, kuna see mõjutab otseselt JavaScripti täitmise kontrollimist.
• style-src: Määratleb lubatud allikad CSS-stiililehtede jaoks.
• img-src: Kontrollib lubatud allikaid piltide jaoks.
• font-src: Määratleb lubatud allikad fontide jaoks.
• connect-src: Määratleb lubatud allikad ühenduste jaoks (nt XMLHttpRequest, fetch, WebSocket).
• media-src: Määratleb lubatud allikad heli ja video jaoks.
• object-src: Määratleb lubatud allikad pistikprogrammide, näiteks Flashi jaoks.
• frame-src: Määratleb lubatud allikad raamide ja iframe'ide jaoks (aegunud, kasutage child-src).
• child-src: Määratleb lubatud allikad veebitöötajate ja manustatud raami sisu jaoks.
• base-uri: Piirab URL-e, mida saab kasutada dokumendi <base> elemendis.
• form-action: Määratleb kehtivad lõpp-punktid vormide esitamiseks.
• frame-ancestors: Määratleb kehtivad vanemad, kuhu lehte saab manustada (nt <frame> või <iframe>).

Igale direktiivile saab määrata allikaavaldiste komplekti. Levinumad allikaavaldised hõlmavad:

• 'self': Lubab ressursse samast päritolust (skeem, host ja port).
• 'none': Blokeerib kõik ressursid.
• 'unsafe-inline': Lubab tekstisisest JavaScripti ja CSS-i. Seda üldiselt ei soovitata ja seda tuleks võimaluse korral vältida. See nõrgendab oluliselt CSP pakutavat kaitset.
• 'unsafe-eval': Lubab kasutada funktsioone nagu eval(), mida sageli kasutatakse XSS-rünnakutes. Samuti väga ebasoovitatav.
• data:: Lubab andme-URL-e (nt base64 kodeeritud pilte).
• blob:: Lubab ressursse blob: skeemiga.
• https://example.com: Lubab ressursse määratud domeenist HTTPS-i kaudu. Saate määrata ka konkreetse tee, näiteks https://example.com/assets/.
• *.example.com: Lubab ressursse mis tahes example.com alldomeenist.

Näited CSP päistest:

Siin on mõned näited, mis illustreerivad, kuidas CSP päiseid kasutatakse:

Näide 1: JavaScripti piiramine samale päritolule

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

              
                Copy
              
            
          

See poliitika lubab brauseril täita JavaScripti ainult lehega samast päritolust. See takistab tõhusalt välistest allikatest sisestatud JavaScripti täitmist. See on hea lähtepunkt paljudele veebisaitidele.

Näide 2: JavaScripti lubamine samast päritolust ja konkreetsest CDN-ist

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

              
                Copy
              
            
          

See poliitika lubab JavaScripti samast päritolust ja domeenist cdn.example.com. See on tavaline veebisaitide puhul, mis kasutavad oma JavaScripti failide edastamiseks CDN-i (sisuedastusvõrku).

Näide 3: Stiililehtede piiramine samale päritolule ja konkreetsele CDN-ile

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

              
                Copy
              
            
          

See poliitika piirab CSS-i laadimist päritolule ja cdn.example.com-ile, takistades pahatahtlike stiililehtede laadimist teistest allikatest.

Näide 4: Põhjalikum poliitika

            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
              
            
          

See on keerulisem näide, mis lubab sisu samast päritolust, JavaScripti samast päritolust ja CDN-ist, CSS-i samast päritolust ja Google Fontsist, pilte samast päritolust ja andme-URL-e ning fonte Google Fontsist. Pange tähele, et peate välised ressursid selgesõnaliselt lubama, kui teie sait neid kasutab.

CSP jõustamine

CSP-d saab jõustada kahel peamisel viisil:

• Ainult aruandlusrežiim: Saate seadistada päise Content-Security-Policy-Report-Only. See päis ei blokeeri ühtegi ressurssi, vaid teatab rikkumistest määratud lõpp-punkti (nt teie kontrollitavale serverile). See on kasulik CSP-poliitika testimiseks enne selle jõustamist, võimaldades teil tuvastada potentsiaalseid probleeme ja vältida oma veebisaidi rikkumist. Brauser proovib endiselt ressursse laadida, kuid annab arendajakonsoolis hoiatuse ja saadab aruande teie määratud lõpp-punkti. Aruanne sisaldab üksikasju rikkumise kohta, näiteks blokeeritud ressursi allikat ja rikkunud direktiivi.
• Jõustamisrežiim: Kui kasutate päist Content-Security-Policy, jõustab brauser poliitikat aktiivselt. Kui ressurss rikub poliitikat (nt skript laaditakse volitamata allikast), blokeerib brauser selle. See on CSP turvalisuse jaoks ettenähtud ja kõige tõhusam viis.

JavaScripti täitmine ja CSP

CSP ja JavaScripti täitmise vaheline koostoime on kriitilise tähtsusega. CSP direktiiv script-src on peamine kontrollpunkt selle üle, kuidas JavaScripti käsitletakse. Kui brauser puutub kokku JavaScriptiga, kontrollib see CSP päise direktiivi script-src. Kui JavaScripti allikas on lubatud, täidab brauser selle. Kui allikas pole lubatud, blokeeritakse skript ja kui aruandlus on lubatud, genereeritakse rikkumisaruanne.

Mõju JavaScripti täitmisele

CSP mõjutab oluliselt seda, kuidas te oma JavaScripti koodi kirjutate ja struktureerite. Täpsemalt võib see mõjutada:

• Tekstisisene JavaScript: Otse teie HTML-i <script> siltide sees kirjutatud JavaScript on sageli piiratud. 'unsafe-inline' kasutamine script-src direktiivis leevendab seda piirangut, kuid on tungivalt ebasoovitatav. Parem lähenemine on viia tekstisisene JavaScript välistesse JavaScripti failidesse.
• eval() ja muu dünaamiline koodi täitmine: Funktsioonid nagu eval(), setTimeout() stringargumendiga ja new Function() on sageli piiratud. Allikaavaldis 'unsafe-eval' on saadaval, kuid seda tuleks vältida. Selle asemel refaktoreerige oma koodi, et neid praktikaid vältida või kasutage alternatiivseid meetodeid.
• Välised JavaScripti failid: CSP kontrollib, milliseid väliseid JavaScripti faile saab laadida. See on peamine kaitse XSS-rünnakute vastu, mis üritavad pahatahtlikke skripte sisestada.
• Sündmuste käsitlejad: Tekstisisesed sündmuste käsitlejad (nt <button onclick="myFunction()"></button>) on sageli blokeeritud, kui 'unsafe-inline' pole lubatud. Parem praktika on lisada sündmuste kuulajad JavaScripti failides.

Parimad praktikad JavaScripti täitmiseks CSP-ga

CSP tõhusaks kasutamiseks ja JavaScripti täitmise turvamiseks kaaluge järgmisi parimaid praktikaid:

• Vältige tekstisisest JavaScripti: Viige kogu JavaScripti kood välistesse .js failidesse. See on kõige mõjukam asi, mida saate teha.
• Vältige eval() ja muud dünaamilist koodi täitmist: Refaktoreerige oma koodi, et vältida eval(), setTimeout() stringargumentidega ja new Function() kasutamist. Need on levinud rünnakute vektorid.
• Kasutage tekstisiseste skriptide jaoks nonce'e või räsiväärtusi (vajadusel): Kui peate absoluutselt kasutama tekstisiseseid skripte (nt pärandkoodi jaoks), kaaluge nonce (unikaalne, juhuslikult genereeritud string) või räsi (skripti sisu krüptograafiline kokkuvõte) kasutamist. Lisate nonce'i või räsi oma CSP päisesse ja skripti sildile. See võimaldab brauseril skripti täita, kui see vastab määratud kriteeriumidele. See on turvalisem alternatiiv kui 'unsafe-inline', kuid see lisab keerukust.
• Kasutage ranget CSP-poliitikat: Alustage piirava CSP-poliitikaga (nt script-src 'self';) ja leevendage seda järk-järgult vastavalt vajadusele. Enne poliitika jõustamist jälgige rikkumisi, kasutades päist Content-Security-Policy-Report-Only.
• Vaadake regulaarselt üle ja värskendage oma CSP-poliitikat: Teie veebirakendus areneb aja jooksul, nagu ka teie CSP-poliitika. Vaadake oma poliitikat regulaarselt üle ja värskendage, et tagada selle jätkuv piisav kaitse. See hõlmab uute funktsioonide lisamist, kolmandate osapoolte teekide integreerimist või CDN-i konfiguratsiooni muutmist.
• Kasutage veebirakenduse tulemüüri (WAF): WAF aitab tuvastada ja leevendada rünnakuid, mis võivad teie CSP-st mööda hiilida. WAF toimib täiendava kaitsekihina.
• Kaaluge turvalisust disainis: Rakendage turvapõhimõtteid oma projekti algusest peale, sealhulgas turvalisi kodeerimispraktikaid ja regulaarseid turvaauditeid.

CSP tegevuses: reaalse maailma näited

Vaatame mõningaid reaalseid stsenaariume ja seda, kuidas CSP aitab haavatavusi leevendada:

Stsenaarium 1: XSS-rünnakute ennetamine välistest allikatest

Veebisait lubab kasutajatel kommentaare esitada. Ründaja sisestab kommentaari pahatahtliku JavaScripti. Ilma CSP-ta täidaks brauser sisestatud skripti. CSP-ga, mis lubab skripte ainult samast päritolust (script-src 'self';), blokeerib brauser pahatahtliku skripti, kuna see pärineb teisest allikast.

Stsenaarium 2: XSS-rünnakute ennetamine usaldusväärse CDN-i kompromiteerimisel

Veebisait kasutab oma JavaScripti failide edastamiseks CDN-i (sisuedastusvõrku). Ründaja kompromiteerib CDN-i ja asendab legitiimsed JavaScripti failid pahatahtlikega. CSP-ga, mis määrab CDN-i domeeni (nt script-src 'self' cdn.example.com;), on veebisait kaitstud, kuna see piirab täitmist ainult konkreetsele CDN-i domeenile hostitud failidele. Kui kompromiteeritud CDN kasutab teist domeeni, blokeeriks brauser pahatahtlikud skriptid.

Stsenaarium 3: Riski leevendamine kolmandate osapoolte teekidega

Veebisait integreerib kolmanda osapoole JavaScripti teegi. Kui see teek on kompromiteeritud, saab ründaja sisestada pahatahtlikku koodi. Range CSP kasutamisega saavad arendajad piirata JavaScripti täitmist kolmanda osapoole teegist, määrates oma CSP-poliitikas allikadirektiivid. Näiteks, määrates kolmanda osapoole teegi konkreetsed päritolud, saab veebisait end kaitsta võimalike ekspluateerimiste eest. See on eriti oluline avatud lähtekoodiga teekide puhul, mida kasutatakse sageli paljudes projektides üle maailma.

Globaalsed näited:

Mõelge maailma mitmekesisele digitaalsele maastikule. Riigid nagu India, oma suure rahvaarvu ja laialdase internetiühendusega, seisavad sageli silmitsi ainulaadsete turvaprobleemidega ühendatud seadmete arvu suurenemise tõttu. Samamoodi on Euroopa piirkondades, kus kehtivad ranged GDPR-i (isikuandmete kaitse üldmääruse) nõuded, turvaline veebirakenduste arendamine esmatähtis. CSP kasutamine ja turvaliste JavaScripti praktikate rakendamine aitab organisatsioonidel kõigis neis piirkondades täita oma turvanõudeid. Riikides nagu Brasiilia, kus e-kaubandus kasvab kiiresti, on veebitehingute turvamine CSP-ga ülioluline nii ettevõtte kui ka tarbija kaitsmiseks. Sama kehtib Nigeerias, Indoneesias ja igas riigis.

Täpsemad CSP tehnikad

Lisaks põhitõdedele on mitmeid täpsemaid tehnikaid, mis võivad teie CSP rakendamist täiustada:

• Nonce-põhine CSP: Tekstisiseste skriptidega töötamisel pakuvad nonce'id turvalisemat alternatiivi kui 'unsafe-inline'. Nonce on unikaalne, juhuslikult genereeritud string, mille genereerite iga päringu jaoks ja lisate nii oma CSP päisesse (script-src 'nonce-TEIE_NONCE';) kui ka <script> sildile (<script nonce="TEIE_NONCE">). See ütleb brauserile, et ta täidaks ainult skripte, millel on sobiv nonce. See lähenemine piirab oluliselt ründajate võimalusi pahatahtliku koodi sisestamiseks.
• Räsipõhine CSP (SRI - alamaressursi terviklikkus): See võimaldab teil määrata skripti sisu krüptograafilise räsi (nt kasutades SHA-256 algoritmi). Brauser täidab skripti ainult siis, kui selle räsi vastab CSP päises olevale räsile. See on teine viis tekstisiseste skriptide (vähem levinud) või väliste skriptide käsitlemiseks. Alamaressursi terviklikkust kasutatakse tavaliselt väliste ressursside, nagu CSS ja JavaScripti teekide puhul, ning see kaitseb kompromiteeritud CDN-i riski eest, mis edastab pahatahtlikku koodi, mis erineb kavandatud teegist.
• CSP aruandluse API: CSP aruandluse API võimaldab teil koguda üksikasjalikku teavet CSP rikkumiste kohta, sealhulgas rikkunud direktiivi, blokeeritud ressursi allika ja lehe URL-i, kus rikkumine toimus. See teave on oluline teie CSP-poliitika jälgimiseks, tõrkeotsinguks ja täiustamiseks. Mitmed tööriistad ja teenused aitavad teil neid aruandeid töödelda.
• CSP ehitamise tööriistad: Tööriistad aitavad teil genereerida ja testida CSP-poliitikaid, näiteks CSP Evaluator ja veebipõhised CSP ehitajad. Need võivad lihtsustada teie poliitikate loomise ja haldamise protsessi.

JavaScripti täitmine ja turvalisuse parimad praktikad

Lisaks CSP-le kaaluge järgmisi üldisi turvalisuse parimaid praktikaid seoses JavaScriptiga:

• Sisendi valideerimine ja puhastamine: Valideerige ja puhastage alati kasutaja sisendit serveri- ja kliendipoolsel tasandil, et vältida XSS-i ja muid sisestamisrünnakuid. Puhastage andmeid, et eemaldada või kodeerida potentsiaalselt ohtlikke märke, näiteks neid, mida kasutatakse skripti käivitamiseks.
• Turvalised kodeerimispraktikad: Järgige turvalisi kodeerimispõhimõtteid, näiteks kasutage parameetritega päringuid SQL-i süstimise vältimiseks ja vältige tundlike andmete salvestamist kliendipoolses koodis. Olge teadlik sellest, kuidas kood käsitleb potentsiaalselt tundlikke andmeid.
• Regulaarsed turvaauditid: Viige läbi regulaarseid turvaauditeid, sealhulgas läbistustestimist, et tuvastada ja lahendada haavatavusi oma veebirakendustes. Turvaaudit, tuntud ka kui läbistustest, on süsteemi simuleeritud rünnak. Need auditid on olulised haavatavuste avastamiseks, mida ründajad saavad ära kasutada.
• Hoidke sõltuvused ajakohasena: Värskendage regulaarselt oma JavaScripti teeke ja raamistikke uusimatele versioonidele, et paigata teadaolevaid haavatavusi. Haavatavad teegid on suur turvaprobleemide allikas. Kasutage sõltuvuste haldamise tööriistu värskenduste automatiseerimiseks.
• Rakendage HTTP Strict Transport Security (HSTS): Veenduge, et teie veebirakendus kasutab HTTPS-i ja rakendab HSTS-i, et sundida brausereid alati teie saidiga ühenduma HTTPS-i kaudu. See aitab vältida vahendajarünnakuid (man-in-the-middle attacks).
• Kasutage veebirakenduse tulemüüri (WAF): WAF lisab täiendava turvakihi, filtreerides pahatahtlikku liiklust ja ennetades rünnakuid, mis mööduvad muudest turvameetmetest. WAF suudab tuvastada ja leevendada pahatahtlikke päringuid, näiteks SQL-i süstimisi või XSS-katseid.
• Harige oma arendusmeeskonda: Veenduge, et teie arendusmeeskond mõistab veebiturvalisuse parimaid praktikaid, sealhulgas CSP-d, XSS-i ennetamist ja turvalisi kodeerimispõhimõtteid. Meeskonna koolitamine on kriitiline investeering turvalisusesse.
• Jälgige turvaohte: Seadistage jälgimis- ja hoiatussüsteemid, et turvaintsidente kiiresti tuvastada ja neile reageerida. Tõhus jälgimine aitab tuvastada potentsiaalseid turvaohte ja neile reageerida.

Kõike kokku pannes: praktiline juhend

Loome lihtsustatud näite, et illustreerida, kuidas neid kontseptsioone rakendada.

Stsenaarium: Lihtne veebisait kontaktivormiga, mis kasutab JavaScripti vormi esitamiste käsitlemiseks.

1. Samm 1: Analüüsige rakenduse sõltuvusi: Tehke kindlaks kõik JavaScripti failid, välised ressursid (nagu CDN-id) ja tekstisisesed skriptid, mida teie rakendus kasutab. Tuvastage kõik skriptid, mis on vajalikud nõuetekohaseks toimimiseks.
2. Samm 2: Viige JavaScript välistesse failidesse: Viige kogu tekstisisene JavaScript eraldi .js failidesse. See on fundamentaalne.
3. Samm 3: Määratlege põhiline CSP päis: Alustage piirava CSP-ga. Näiteks, kui kasutate sama päritolu, võiksite alustada järgmisega:

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

4. Samm 4: Testige CSP-d ainult aruandlusrežiimis: Rakendage esialgu Content-Security-Policy-Report-Only päis, et tuvastada võimalikud konfliktid. Koguge aruanded ja analüüsige neid.
5. Samm 5: Lahendage kõik rikkumised: Aruannete põhjal kohandage CSP päist, et lubada vajalikke ressursse. See võib hõlmata konkreetsete CDN-domeenide valgesse nimekirja lisamist või, kui see on absoluutselt vajalik, nonce'ide või räside kasutamist tekstisiseste skriptide jaoks (kuigi seda on harva vaja, kui järgitakse parimaid praktikaid).
6. Samm 6: Rakendage ja jälgige: Kui olete kindel, et CSP toimib õigesti, lülituge Content-Security-Policy päisele. Jälgige pidevalt oma rakendust rikkumiste osas ja kohandage oma CSP-poliitikat vastavalt vajadusele.
7. Samm 7: Rakendage sisendi valideerimine ja puhastamine: Veenduge, et serveri- ja kliendipoolne kood valideerib ja puhastab kasutaja sisendit haavatavuste vältimiseks. See on kriitilise tähtsusega XSS-rünnakute eest kaitsmiseks.
8. Samm 8: Regulaarsed auditid ja värskendused: Vaadake regulaarselt üle ja värskendage oma CSP-poliitikat, pidades silmas uusi funktsioone, integratsioone ja mis tahes muudatusi rakenduse arhitektuuris või sõltuvustes, millele see tugineb. Rakendage regulaarseid turvaauditeid, et tabada ettenägematuid probleeme.

Kokkuvõte

Sisuturvapoliitika (CSP) on kaasaegse veebiturvalisuse kriitiline komponent, mis töötab koos JavaScripti täitmise praktikatega, et kaitsta teie veebirakendusi paljude ohtude eest. Mõistes, kuidas CSP direktiivid kontrollivad JavaScripti täitmist ja järgides turvalisuse parimaid praktikaid, saate oluliselt vähendada XSS-rünnakute riski ja parandada oma veebirakenduste üldist turvalisust. Pidage meeles, et turvalisusele tuleb läheneda kihiti, integreerides CSP-d muude turvameetmetega, nagu sisendi valideerimine, veebirakenduste tulemüürid (WAF) ja regulaarsed turvaauditid. Neid põhimõtteid järjepidevalt rakendades saate luua oma kasutajatele turvalisema ja kindlama veebikogemuse, olenemata nende asukohast või kasutatavast tehnoloogiast. Oma veebirakenduste turvamine ei kaitse mitte ainult teie andmeid, vaid loob ka usalduse oma globaalse publikuga ning ehitab üles usaldusväärsuse ja turvalisuse maine.