CSP-generátor — Content Security Policy, a veszélyes részek jelölésével
CSP-generátor
A direktívák és források bejelölésével ez az oldal összeállít egy helyes, egysoros Content-Security-Policy értéket a válaszfejléchez vagy <meta> címkéhez — a lényeges megjegyzésekkel együtt: mely direktívák sosem esnek vissza a default-src-re, mikor írja felül a hash vagy a nonce csendben az unsafe-inline-t, és mit kapcsol ki a strict-dynamic. A beépített SHA-256/384/512 hash-generátor az inline szkripteket és stílusokat 'sha256-…' forrásokká alakítja. Minden a böngészőben fut; semmi nem töltődik fel.
Lekérési direktívák — honnan származhat a tartalom
A be nem jelölt direktívák egyszerűen kimaradnak a szabályzatból; forrás nélküli bejelölés figyelmen kívül marad. A 'none' kizárja a sorában lévő többi jelölőnégyzetet. A további források mező vesszővel elválasztott listát vár: gazdaneveket (cdn.example.com), sémákat (https:), hash-eket és nonce-okat, idézőjellel vagy anélkül.
direktíva
'self'
'none'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
data:
blob:
további források
Dokumentumdirektívák — mit tehet az oldal
Ezt a négyet nem érinti a default-src visszaesés: ha kimaradnak, az „nincs korlátozás” jelentésű, ezért egy teljes szabályzat explicit módon állítja be őket.
direktíva
'self'
'none'
további források
Kapcsolók, nonce és jelentéstétel
szkript nonce
report-uri
report-to
Szabályzat
Még nincs semmi készítve. Források bejelölése után a Szabályzat készítése gomb használható, vagy betölthető az OWASP-alapvonal minta.
Hash-generátor inline szkriptekhez és stílusokhoz
A <script> és a </script> közötti pontos tartalom (vagy a stílusblokk) beillesztése — bájtról bájtra, a sor eleji vagy végi újsor nélkül — és algoritmus kiválasztása szükséges. Az eredmény az a 'sha256-…' forrás, amelyet a CSP 3 vár.
A hash kimenete itt jelenik meg.
Lehetőség szerint fejlécként telepítendő, ne meta-címkeként. A válaszfejléc a teljes CSP: a frame-ancestors, report-uri és report-to csak ott működik, a fejléc pedig a HTML első bájtjának feldolgozása előtt érvényesül. A meta-címke a tartalék statikus fájlokhoz, amelyekhez nincs szerverkonfiguráció. A tényleges válaszfejlécek ellenőrzése a biztonsági fejlécellenőrzőn történhet, a nyers válaszblokkok szétbontása pedig a HTTP-fejléc-elemzőn.
Önteszt Az építőt rögzített állapotokon futtatja újra: a forrássorrend, a 'none' kölcsönös kizárása, az OWASP-alapvonal karakterlánca, a nonce- és hash-idézőjelezés, a base-uri / form-action / frame-ancestors visszaesés nélküli megjegyzései, az unsafe-inline felülírása nonce vagy hash által, a strict-dynamic megjegyzései, a Report-Only fejlécnevek, a meta-címkés kizárások, a hash-generátor függetlenül számolt SHA-vektorokkal, valamint a negatív esetek. Semmi nem kerül elküldésre.
Mi az a tartalombiztonsági szabályzat?
Egy mondatban: a CSP olyan fehérlista, amelyet a szerver küld az oldallal, és amely pontosan megmondja a böngészőnek, honnan szabad szkripteket, stílusokat, képeket és kapcsolatokat betölteni — így még akkor is, ha a támadó HTML-t juttat be, a bejuttatott szkript nem töltődik be, mert forrása nincs a listán.
igen — a be nem jelölt direktíva a default-src-t örökli
Dokumentumdirektívák
base-uri, form-action, frame-ancestors, sandbox
az oldal működése (beágyazhatóság, űrlapok küldése, relatív URL-ek feloldása)
nem — mindegyiket explicit módon kell megadni
Jelentés és egyéb
report-uri, report-to, upgrade-insecure-requests
ahová a sértési jelentések kerülnek, és a régi URL-ek frissítése
nem (nem lekérési direktívák)
A legélesebb szélek, bekezdésenként egy
'unsafe-inline' vs. hash-ek és nonce-ok. Ha egy direktíva nonce-t vagy bármilyen hash-forrást tartalmaz, a CSP 3 szerint az 'unsafe-inline'figyelmen kívül marad — csak a régi böngészőknek marad ott. Ezért jelenti az, hogy „nonce-t adtunk hozzá, de a biztonság kedvéért megtartottuk az unsafe-inline-t”, valójában azt, hogy a modern böngészők a nonce-t érvényesítik. A generátor megjelöli ezt a kombinációt, így döntés lesz belőle, nem véletlen.
A strict-dynamic kikapcsolja a megengedőlistát. Ha a script-src-ben a strict-dynamic szerepel, a gazdaforrások, sémák, 'self', 'unsafe-inline' és data: szkriptek esetén figyelmen kívül maradnak; csak a nonce-ok és hash-ek számítanak, és az általuk betöltött szkriptek további szkripteket tölthetnek be. Ez a betöltőszkriptek futtatásának modern módja — de a script-src többi listája így csupán díszlet.
A meta-címkék másodrangúak. A frame-ancestors, report-uri és report-to figyelmen kívül marad a <meta http-equiv>-ben. A generátor megmutatja, a szabályzat mely részei nem fognak csendben érvényesülni.
Gyakori hibák
A default-src *-gel és hosszú kivétellistával való indulás. Fordítva érdemes dolgozni: szoros default-src 'self'-rel indulni, majd csak azokat a direktívákat bővíteni, amelyekre szükség van. A szűk szabályzatok tesztelés közben hangosan hibáznak; a bő szabályzatok örökre csendben hibáznak.
Az, hogy script-src 'unsafe-inline' 'unsafe-eval' beállítás után készre jelentjük. Ez a szabályzat szinte semmit nem blokkol abból, amit egy XSS-támadás el akar érni. Nonce-szal vagy hash-sel kell ellátni a szkripteket, hozzá kell adni a strict-dynamic-ot, és az éles környezetben érdemes futtatni a report-only módot a regressziók kiszűrésére.
Elfelejteni, hogy a default-src nem fed le mindent. A base-uri, form-action, frame-ancestors és sandbox nem rendelkezik visszaeséssel — ez a valós CSP-bevezetések leggyakrabban idézett hiánya.
Tesztelés először kényszerítő módban. Egy hétig Report-Only módban, gyűjtővel futtatva olvasni a jelentéseket, majd átállítani a kényszerítésre. Az a szabályzat, amely a pénztárat töri el, rosszabb, mint nincs szabályzat.
A szóközök eltérő hashelése. A hash az inline blokk pontos bájtjait fedi; egy „hasznos” buildlépés, amely a záró újsorokat levágja, minden hash-t megváltoztat. A hash-eket abból kell generálni, ami ténylegesen szállításra kerül, nem a forrásból.
GYIK
Szükséges-e a default-src, ha minden direktívát felsorolunk? Nem, de alapszintként érdemes megtartani: az új lekérési direktívák a jövőbeli böngészőkben így az alapszintre, nem pedig az „engedélyezett” állapotra esnek vissza.
Mit tesz valójában az upgrade-insecure-requests? Utasítja a böngészőt, hogy minden olyan http:// URL-t, amelyet az oldal betöltene — képeket, stílusokat, lekéréseket — kérés előtt https://-re kell átírni. Migrációs eszköz; a végállapot az, hogy az oldalnak egyáltalán nincs http:// URL-je.
Nonce vagy hash? Nonce, ha a szerveres válasz felett van kontroll (válaszonként véletlen érték, mind a fejlécben, mind minden szkriptcímkében). Hash, ha a HTML statikus vagy gyorsítótárazott. Soha nem statikus nonce — az a nonce, amely nem változik, csak az unsafe-inline többletlépésekkel.
Miért nem érkeznek meg a sértési jelentések, ha a szabályzat már el van küldve? Ellenőrizendő, hogy Report-Only (csak jelentés) módban van-e, hogy a report-uri POST-ot fogadó gyűjtőre mutat-e, és hogy beállították-e a modern report-to direktíva által igényelt Reporting-Endpoints / Report-To mechanizmust is.
Pótolja-e a CSP a többi védelmet? Nem. Ez egy réteg: a kimenet kódolását továbbra is el kell végezni, a sütik maradjanak HttpOnly és Secure védelem mögött, a HSTS pedig maradjon. Az oldal biztonsági fejlécellenőrzője a teljes készletet értékeli.
