Õppige JavaScripti turvalisust meie põhjaliku sisu turvapoliitika (CSP) juhendi abil. Õppige rakendama CSP päiseid, maandama XSS-i ja andmete süstimist ning kaitsma oma globaalseid veebirakendusi.
Tugevda oma veebirakendust: põhjalik juhend JavaScripti turvapäiste ja sisu turvapoliitika (CSP) rakendamise kohta
Tänapäeva omavahel seotud digitaalses maastikus on veebirakenduste turvalisus ülimalt tähtis. Arendajatena on meie ülesanne mitte ainult ehitada funktsionaalseid ja kasutajasõbralikke kogemusi, vaid ka kaitsta neid paljude arenevate ohtude eest. Üks võimsamaid tööriistu meie arsenalis esiotsa turvalisuse suurendamiseks on asjakohaste HTTP turvapäiste rakendamine. Nende hulgas paistab sisu turvapoliitika (CSP) silma kriitilise kaitsemehhanismina, eriti dünaamilise sisu ja JavaScripti käivitamise korral.
See põhjalik juhend süveneb JavaScripti turvapäiste keerukusse, keskendudes laseriga sisu turvapoliitikale. Me uurime, mis on CSP, miks see on kaasaegsete veebirakenduste jaoks hädavajalik, ja pakume praktilisi samme selle rakendamiseks. Meie eesmärk on varustada arendajad ja turvaprofessionaalid kogu maailmas teadmistega vastupidavamate ja turvalisemate veebikogemuste loomiseks.
Maastiku mõistmine: miks JavaScripti turvalisus on oluline
JavaScript, olles küll abiks interaktiivsete ja dünaamiliste veebilehtede loomisel, tekitab ka ainulaadseid turvaprobleeme. Pahatahtlikud toimijad saavad ära kasutada selle võimet manipuleerida dokumendi objektimudeliga (DOM), teha võrgupäringuid ja käivitada koodi otse kasutaja brauseris. Levinud JavaScriptiga seotud haavatavused on järgmised:
- Ristsaitide skriptimine (XSS): ründajad süstivad pahatahtlikku JavaScripti koodi veebilehtedele, mida teised kasutajad vaatavad. See võib viia sessiooni kaaperdamise, andmete varguse või suunamiseni pahatahtlikele saitidele.
- Andmete süstimine: kasutaja sisendi ebaturvalise käsitlemise ärakasutamine, võimaldades ründajatel süstida ja käivitada suvalist koodi või käske.
- Pahatahtlikud kolmandate osapoolte skriptid: kaasa arvatud skriptid usaldusväärsetest allikatest, mis võivad olla kahjustatud või tahtlikult pahatahtlikud.
- DOM-põhine XSS: haavatavused kliendipoolses JavaScripti koodis, mis manipuleerib DOM-i ebaturvalisel viisil.
Kuigi turvalised kodeerimispraktikad on esimene kaitseliin, pakuvad HTTP turvapäised täiendavat kaitsekihti, pakkudes deklaratiivset viisi turvapoliitikate jõustamiseks brauseri tasemel.
Turvapäiste jõud: kaitse alus
HTTP turvapäised on direktiivid, mille veebiserver saadab brauserile, juhendades teda, kuidas veebisaidi sisu käsitleda. Need aitavad maandada erinevaid turvariske ja on kaasaegse veebiturvalisuse nurgakivi. Mõned peamised turvapäised on järgmised:
- Strict-Transport-Security (HSTS): jõustab HTTPS-i kasutamise, kaitstes man-in-the-middle rünnakute eest.
- X-Frame-Options: takistab klõpsamisrünnakuid, kontrollides, kas lehte saab renderdada
<iframe>,<frame>või<object>. - X-Content-Type-Options: takistab brauseritel MIME-i sisu tüübi nuusutamist, maandades teatud tüüpi rünnakuid.
- X-XSS-Protection: võimaldab brauseri sisseehitatud XSS-filtri (kuigi selle on suures osas asendanud CSP robustsemad võimalused).
- Referrer-Policy: kontrollib, kui palju suunaja teavet saadetakse koos päringutega.
- Content-Security-Policy (CSP): meie arutelu keskmes on võimas mehhanism, et kontrollida ressursse, mida brauseril on lubatud antud lehe jaoks laadida.
Kuigi kõik need päised on olulised, pakub CSP enneolematut kontrolli skriptide ja muude ressursside käivitamise üle, muutes selle oluliseks tööriistaks JavaScriptiga seotud haavatavuste maandamisel.
SĂĽgav sukeldumine sisu turvapoliitikasse (CSP)
Sisu turvapoliitika (CSP) on täiendav turvakiht, mis aitab tuvastada ja maandada teatud tüüpi rünnakuid, sealhulgas ristsaitide skriptimise (XSS) ja andmete süstimise rünnakuid. CSP pakub veebisaidi administraatoritele deklaratiivset viisi, kuidas määrata, milliseid ressursse (skriptid, stiililehed, pildid, fondid jne) on lubatud nende veebilehtedel laadida ja käivitada. Vaikimisi, kui poliitikat pole määratletud, lubavad brauserid üldiselt ressursse laadida mis tahes päritolust.
CSP töötab, võimaldades teil määratleda iga ressursi tüübi jaoks usaldusväärsete allikate valge nimekirja. Kui brauser saab CSP päise, jõustab see need reeglid. Kui ressurssi taotletakse mittetöötava allikast, blokeerib brauser selle, takistades seeläbi potentsiaalselt pahatahtliku sisu laadimist või käivitamist.
Kuidas CSP töötab: põhimõisted
CSP rakendatakse, saates serverist kliendile HTTP päise Content-Security-Policy. See päis sisaldab rea direktiive, millest igaüks kontrollib ressursi laadimise konkreetset aspekti. JavaScripti turvalisuse kõige olulisem direktiiv on script-src.
Tüüpiline CSP päis võib välja näha selline:
Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'; img-src *; media-src media1.com media2.com; style-src 'self' 'unsafe-inline'
Võtame lahti mõned peamised direktiivid:
Peamised CSP direktiivid JavaScripti turvalisuse jaoks
default-src: see on varukoopia direktiiv. Kui konkreetset direktiivi (ntscript-src) pole määratletud, kasutataksedefault-src, et kontrollida selle ressursi tüübi lubatud allikaid.script-src: see on kõige olulisem direktiiv JavaScripti käivitamise kontrollimiseks. See määrab JavaScripti jaoks kehtivad allikad.object-src: määratleb kehtivad allikad sellistele pluginatele nagu Flash. Üldiselt on soovitatav seada see väärtusele'none', et pluginad täielikult keelata.base-uri: piirab URL-e, mida saab kasutada dokumendi elemendis<base>.form-action: piirab URL-e, mida saab kasutada dokumendist esitatud HTML-vormide sihtmärgina.frame-ancestors: kontrollib, millised päritolud saavad praeguse lehe kaadrisse manustada. See onX-Frame-Optionskaasaegne asendus.upgrade-insecure-requests: juhendab brauserit käsitlema kõiki saidi ebaturvalisi URL-e (HTTP) nii, nagu need oleksid uuendatud turvalisteks URL-ideks (HTTPS).
Allika väärtuste mõistmine CSP-s
CSP direktiivides kasutatavad allika väärtused määratlevad, mida peetakse usaldusväärseks päritoluks. Levinud allika väärtused on järgmised:
'self': lubab ressursse samast päritolust nagu dokument. See hõlmab skeemi, hosti ja porti.'unsafe-inline': lubab sisemisi ressursse, nagu<script>plokid ja sisemised sündmuste käsitlejad (ntonclickatribuudid). Kasutage äärmise ettevaatusega! Sisemiste skriptide lubamine nõrgendab märkimisväärselt CSP tõhusust XSS-i vastu.'unsafe-eval': lubab kasutada JavaScripti hindamisfunktsioone, nagueval()jasetTimeout()koos stringi argumentidega. Vältige seda, kui vähegi võimalik.*: metamärk, mis lubab mis tahes päritolu (kasutage väga säästlikult).- Skeem: nt
https:(lubab mis tahes hosti HTTPS-is). - Host: nt
example.com(lubab mis tahes skeemi ja porti selles hostis). - Skeem ja host: nt
https://example.com. - Skeem, host ja port: nt
https://example.com:8443.
Sisu turvapoliitika rakendamine: samm-sammult lähenemine
CSP tõhus rakendamine nõuab hoolikat planeerimist ja põhjalikku arusaamist teie rakenduse ressursisõltuvustest. Valesti konfigureeritud CSP võib teie saidi rikkuda, samas kui hästi konfigureeritud CSP suurendab oluliselt selle turvalisust.
1. samm: auditeerige oma rakenduse ressursse
Enne CSP määratlemist peate teadma, kust teie rakendus ressursse laadib. See hõlmab järgmist:
- Sisemised skriptid: teie enda JavaScripti failid.
- Kolmandate osapoolte skriptid: analüütikateenused (nt Google Analytics), reklaamivõrgud, sotsiaalmeedia vidinad, raamatukogude CDN-id (nt jQuery, Bootstrap).
- Sisemised skriptid ja sündmuste käsitlejad: mis tahes JavaScripti kood, mis on otse HTML-i siltidesse või
<script>plokkidesse manustatud. - Stiililehed: nii sisemised kui ka välised.
- Pildid, meedia, fondid: kus neid ressursse majutatakse.
- Vormid: vormide esitamise sihtmärgid.
- Veebitöötajad ja teenustöötajad: kui see on asjakohane.
Tööriistad, nagu brauseri arendajakonsoolid ja spetsiaalsed turvaskannerid, aitavad teil neid ressursse tuvastada.
2. samm: määratlege oma CSP poliitika (alustage aruandlusrežiimis)
Kõige turvalisem viis CSP rakendamiseks on alustada aruandlusrežiimis. See võimaldab teil rikkumisi jälgida ilma ressursse blokeerimata. Saate seda saavutada, kasutades päist Content-Security-Policy-Report-Only. Kõik rikkumised saadetakse määratud aruandluse lõpp-punkti.
Näide ainult aruandluse päisest:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; connect-src 'self' api.example.com;
Aruandluse lubamiseks peate määrama ka direktiivi report-uri või report-to:
report-uri: (aegunud, kuid siiski laialdaselt toetatud) määrab URL-i, kuhu rikkumisaruanded tuleks saata.report-to: (uuem, paindlikum) määrab JSON-objekti, mis kirjeldab aruandluse lõpp-punkte.
Näide koos report-uri:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-violation-report-endpoint;
Seadistage taustalõpp-punkt (nt Node.js, Python, PHP), et neid aruandeid vastu võtta ja logida. Analüüsige aruandeid, et mõista, milliseid ressursse blokeeritakse ja miks.
3. samm: täpsustage oma poliitikat iteratiivselt
Rikkumisaruannete põhjal kohandate oma CSP direktiive järk-järgult. Eesmärk on luua poliitika, mis lubab kõiki seaduslikke ressursse, blokeerides samas kõik potentsiaalselt pahatahtlikud ressursid.
Levinud kohandused on järgmised:
- Konkreetsete kolmandate osapoolte domeenide lubamine: kui seaduslik kolmanda osapoole skript (nt JavaScripti teegi CDN) on blokeeritud, lisage selle domeen direktiivi
script-src. Näiteks:script-src 'self' https://cdnjs.cloudflare.com; - Sisemiste skriptide käsitlemine: kui teil on sisemisi skripte või sündmuste käsitlejaid, on teil paar võimalust. Kõige turvalisem on oma kood ümber kujundada, et need eraldi JavaScripti failidesse teisaldada. Kui see pole kohe teostatav:
- Kasutage nonse (üks kord kasutatud number): genereerige iga päringu jaoks unikaalne, ettearvamatu märk (nonce) ja lisage see direktiivi
script-src. Seejärel lisage siltidele<script>atribuutnonce-. Näide:script-src 'self' 'nonce-random123';ja<script nonce="random123">alert('hello');</script>. - Kasutage räsi: sisemiste skriptide jaoks, mis ei muutu, saate genereerida skripti sisu krüptograafilise räsi (nt SHA-256) ja lisada selle direktiivi
script-src. Näide:script-src 'self' 'sha256-somehashvalue';. 'unsafe-inline'(viimane abinõu): nagu mainitud, see nõrgendab turvalisust. Kasutage seda ainult siis, kui see on hädavajalik ja ajutise meetmena.
- Kasutage nonse (üks kord kasutatud number): genereerige iga päringu jaoks unikaalne, ettearvamatu märk (nonce) ja lisage see direktiivi
eval()käsitlemine: kui teie rakendus toetubeval()või sarnastele funktsioonidele, peate koodi ümber kujundama, et neid vältida. Kui see on vältimatu, peate lisama'unsafe-eval', kuid see on väga soovitatav.- Piltide, stiilide jne lubamine: sarnaselt kohandage
img-src,style-src,font-srcjne vastavalt oma rakenduse vajadustele.
4. samm: lülituge jõustamisrežiimi
Kui olete kindel, et teie CSP poliitika ei riku seaduslikku funktsionaalsust ja teatab tõhusalt potentsiaalsetest ohtudest, lülituge päisest Content-Security-Policy-Report-Only päisele Content-Security-Policy.
Näide jõustamispäisest:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com; style-src 'self' 'unsafe-inline'; img-src *;
Ärge unustage eemaldada või keelata direktiivi report-uri või report-to jõustamispäisest, kui te ei soovi enam aruandeid saada (kuigi selle säilitamine võib olla kasulik jälgimiseks).
5. samm: pidev jälgimine ja hooldus
Turvalisus ei ole ühekordne seadistus. Kui teie rakendus areneb, lisatakse uusi skripte või kolmandate osapoolte sõltuvusi uuendatakse, võib teie CSP vajada kohandusi. Jälgige jätkuvalt rikkumisaruandeid ja värskendage oma poliitikat vastavalt vajadusele.
Täiustatud CSP tehnikad ja parimad tavad
Lisaks põhilisele rakendusele saavad mitmed täiustatud tehnikad ja parimad tavad veelgi tugevdada teie veebirakenduse turvalisust CSP abil.
1. Etappiline kasutuselevõtt
Suurte või keerukate rakenduste puhul kaaluge CSP etapilist kasutuselevõttu. Alustage lubava poliitikaga ja pingutage seda järk-järgult. Saate CSP aruandlusrežiimis juurutada ka konkreetsetele kasutajasegmentidele või piirkondadele enne täielikku ülemaailmset jõustamist.
2. Majutage oma skripte võimalusel ise
Kuigi CDN-id on mugavad, kujutavad need endast kolmanda osapoole riski. Kui CDN on kahjustatud, võib see teie rakendust mõjutada. Oluliste JavaScripti teekide majutamine oma domeenis, mida pakutakse HTTPS-i kaudu, võib teie CSP-d lihtsustada ja vähendada väliseid sõltuvusi.
3. Kasutage frame-ancestors
Direktiiv frame-ancestors on kaasaegne ja eelistatud viis klõpsamisrünnakute vältimiseks. Selle asemel, et loota ainult X-Frame-Options, kasutage oma CSP-s frame-ancestors.
Näide:
Content-Security-Policy: frame-ancestors 'self' https://partner.example.com;
See võimaldab teie lehe manustada ainult teie enda domeeni ja konkreetse partnerdomeeni abil.
4. Kasutage connect-src API-kõnede jaoks
Direktiiv connect-src kontrollib, kuhu JavaScript saab ühendusi luua (nt kasutades fetch, XMLHttpRequest, WebSocket). See on ülioluline andmete väljajuhtimise eest kaitsmiseks.
Näide:
Content-Security-Policy: default-src 'self'; connect-src 'self' api.internal.example.com admin.external.com;
See võimaldab API-kõnesid ainult teie sisemisele API-le ja konkreetsele välisele haldusteenusele.
5. CSP tase 2 ja edaspidi
CSP on aja jooksul arenenud. CSP tase 2 tutvustas funktsioone, nagu:
unsafe-inlinejaunsafe-evalkui skripti/stiili märksõnad: spetsiifilisus sisemiste stiilide ja skriptide lubamisel.report-todirektiiv: paindlikum aruandlusmehhanism.child-srcdirektiiv: veebitöötajate ja sarnase manustatud sisu allikate kontrollimiseks.
CSP tase 3 lisab jätkuvalt rohkem direktiive ja funktsioone. Uusimate spetsifikatsioonidega kursis olemine tagab, et kasutate kõige tugevamaid turvameetmeid.
6. CSP integreerimine serveripoolsete raamistikega
Enamik kaasaegseid veebiraamistikke pakuvad vahevara või konfiguratsioonivalikuid HTTP päiste, sealhulgas CSP, seadmiseks. Näiteks:
- Node.js (Express): kasutage teeke, nagu `helmet`.
- Python (Django/Flask): lisage päiseid oma vaatefunktsioonidesse või kasutage konkreetset vahevara.
- Ruby on Rails: konfigureerige `config/initializers/content_security_policy.rb`.
- PHP: kasutage funktsiooni `header()` või raamistikupõhiseid konfiguratsioone.
Konsulteerige alati oma raamistiku dokumentatsiooniga soovitatud lähenemisviisi kohta.
7. Dünaamilise sisu ja raamistike käsitlemine
Kaasaegsed JavaScripti raamistikud (React, Vue, Angular) genereerivad sageli koodi dünaamiliselt. See võib muuta CSP rakendamise keeruliseks, eriti sisemiste stiilide ja sündmuste käsitlejate puhul. Nende raamistike soovitatav lähenemisviis on järgmine:
- Vältige võimalikult palju sisemisi stiile ja sündmuste käsitlejaid, kasutades eraldi CSS-faile või raamistikupõhiseid mehhanisme stiili ja sündmuste sidumise jaoks.
- Kasutage nonse või räsi kõigi dünaamiliselt genereeritud skriptisiltide jaoks, kui täielik vältimine pole võimalik.
- Veenduge, et teie raamistiku koostamisprotsess on konfigureeritud töötama koos CSP-ga (nt võimaldades teil süstida nonse skriptisiltidesse).
Näiteks Reacti kasutamisel peate võib-olla konfigureerima oma serveri, et süstida nonce faili `index.html` ja seejärel edastada see nonce oma Reacti rakendusele kasutamiseks dünaamiliselt loodud skriptisiltidega.
Levinud vead ja kuidas neid vältida
CSP rakendamine võib mõnikord põhjustada ootamatuid probleeme. Siin on levinud vead ja kuidas neid lahendada:
- Liiga piiravad poliitikad: oluliste ressursside blokeerimine. Lahendus: alustage aruandlusreĹľiimis ja auditeerige oma rakendust hoolikalt.
'unsafe-inline'ja'unsafe-eval'kasutamine ilma vajaduseta: see nõrgendab oluliselt turvalisust. Lahendus: kujundage kood ümber, et kasutada nonse, räsi või eraldi faile.- Aruandluse vale käsitlemine: aruandluse lõpp-punkti mitte seadistamine või aruannete ignoreerimine. Lahendus: rakendage tugev aruandlusmehhanism ja analüüsige andmeid regulaarselt.
- Alamdomeenide unustamine: kui teie rakendus kasutab alamdomeene, veenduge, et teie CSP reeglid neid selgesõnaliselt hõlmavad. Lahendus: kasutage metamärgiga domeene (nt `*.example.com`) või loetlege iga alamdomeen.
report-onlyja jõustamispäiste segiajamine:report-onlypoliitika rakendamine tootmises võib teie saidi rikkuda. Lahendus: kontrollige oma poliitikat alati aruandlusrežiimis enne jõustamise lubamist.- Brauseri ühilduvuse ignoreerimine: kuigi CSP on laialdaselt toetatud, ei pruugi vanemad brauserid kõiki direktiive täielikult rakendada. Lahendus: pakkuge vanematele brauseritele tagavarasid või sujuvat deaktiveerimist või nõustuge, et neil ei pruugi olla täielikku CSP kaitset.
Ăślemaailmsed kaalutlused CSP rakendamiseks
CSP rakendamisel ĂĽlemaailmsele publikule on olulised mitmed tegurid:
- Mitmekesine infrastruktuur: teie rakendust võidakse majutada erinevates piirkondades või kasutada piirkondlikke CDN-e. Veenduge, et teie CSP lubaks ressursse kõigist asjakohastest päritoludest.
- Erinevad määrused ja vastavus: kuigi CSP on tehniline kontroll, olge teadlik andmete privaatsuse määrustest (nagu GDPR, CCPA) ja veenduge, et teie CSP rakendamine on nendega kooskõlas, eriti seoses andmete edastamisega kolmandatele osapooltele.
- Keel ja lokaliseerimine: veenduge, et kogu dünaamilist sisu või kasutaja loodud sisu käsitletakse turvaliselt, kuna see võib olla süstimisrünnakute vektor olenemata kasutaja keelest.
- Testimine erinevates keskkondades: testige oma CSP poliitikat põhjalikult erinevates võrgutingimustes ja geograafilistes asukohtades, et tagada järjepidev turvalisus ja jõudlus.
Järeldus
Sisu turvapoliitika on võimas ja oluline tööriist kaasaegsete veebirakenduste kaitsmiseks JavaScriptiga seotud ohtude, nagu XSS, eest. Mõistes selle direktiive, rakendades seda süstemaatiliselt ja järgides parimaid tavasid, saate oluliselt parandada oma veebirakenduste turvalisust.
Pidage meeles:
- Auditeerige oma ressursse hoolikalt.
- Alustage aruandlusreĹľiimis, et tuvastada rikkumisi.
- Täpsustage oma poliitikat iteratiivselt, et tasakaalustada turvalisust ja funktsionaalsust.
- Vältige
'unsafe-inline'ja'unsafe-eval'alati, kui võimalik. - Jälgige oma CSP pideva tõhususe tagamiseks.
CSP rakendamine on investeering teie veebirakenduse turvalisusesse ja usaldusväärsusesse. Võttes proaktiivse ja metoodilise lähenemisviisi, saate luua vastupidavamaid rakendusi, mis kaitsevad teie kasutajaid ja teie organisatsiooni veebis esinevate ohtude eest.
Olge turvaline!