CSP-generator — Content Security Policy, med markerte skarpe kanter
CSP-generator
Kryss av for direktivene og kildene, og denne siden setter sammen en korrekt enlinjes Content-Security-Policy for responsheaderen eller <meta>-taggen — pluss notatene som betyr noe: hvilke direktiver som aldri faller tilbake til default-src, når en hash eller nonce stille overstyrer unsafe-inline, og hva strict-dynamic slår av. En innebygd SHA-256/384/512-hashgenerator gjør innlinjeskript og -stiler om til 'sha256-…'-kilder. Alt kjører i nettleseren; ingenting lastes opp.
Fetch-direktiver — hvor innhold kan komme fra
Direktiver uten hake er ganske enkelt fraværende i policyen; en hake uten valgte kilder ignoreres. 'none' kansellerer de andre boksene i sin rad. Boksen ekstra kilder tar en kommaseparert liste: vertsnavn (cdn.example.com), skjemaer (https:), hasher og nonce med eller uten anførselstegn.
direktiv
'self'
'none'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
data:
blob:
ekstra kilder
Dokumentdirektiver — hva selve siden kan gjøre
Disse fire faller ikke tilbake til default-src: å utelate dem betyr «ingen begrensning», så en komplett policy setter dem eksplisitt.
direktiv
'self'
'none'
ekstra kilder
Brytere, nonce og rapportering
skript-nonce
report-uri
report-to
Policy
Ingenting er bygget ennå. Kryss av noen kilder og trykk Bygg policy, eller last inn OWASP-grunnlinjeeksemplet.
Hashgenerator for innlinjeskript og -stiler
Lim inn det nøyaktige innholdet mellom <script> og </script> (eller stilblokken) — byte for byte, uten innledende eller etterfølgende linjeskift — og velg en algoritme. Resultatet er 'sha256-…'-kilden CSP 3 forventer.
Hash-utdata vises her.
Rull ut som en header, ikke en metatag, når det er mulig. Responsheaderen er hele CSP-en: frame-ancestors, report-uri og report-to fungerer bare der, og en header brukes før den første byten av HTML tolkes. Metataggen er reserveløsningen for statiske filer uten serverkonfigurasjon. Kontroller headerne nettstedet faktisk sender på sjekken av sikkerhetsheadere, og løs opp rå responsblokker på HTTP-headertolkeren.
Selvtest Kjører bygger på nytt mot faste tilstander: rekkefølge på kilder, gjensidig utelukkelse av 'none', OWASP-grunnlinjestrengen, anførselstegn for nonce og hash, merknadene om ingen reserveløsning for base-uri / form-action / frame-ancestors, unsafe-inline overstyrt av nonce eller hash, merknadene om strict-dynamic, navn på Report-Only-headere, utelukkelser for metatagger, hashgeneratoren mot uavhengig beregnede SHA-vektorer og de negative veiene. Ingenting sendes noe sted.
Hva er en Content Security Policy?
Med én setning: en CSP er en hvitliste som serveren sender med en side og som forteller nettleseren nøyaktig hvor skript, stiler, bilder og forbindelser får komme fra — så selv om en angriper injiserer HTML, lastes det injiserte skriptet ikke, fordi kilden ikke står på listen.
hva selve siden kan gjøre (bli innebygd, sende skjemaer til, løse relative URL-er mot)
nei — hver må settes eksplisitt
Rapportering og diverse
report-uri, report-to, upgrade-insecure-requests
hvor brudd-rapporter går, og oppgradering av gamle URL-er
nei (de er ikke fetch-direktiver)
De skarpeste kantene, ett avsnitt hver
'unsafe-inline' kontra hash og nonce. Hvis et direktiv inneholder en nonce eller en hashkilde, sier CSP 3 at 'unsafe-inline'ignoreres — den står der bare for svært gamle nettlesere. Derfor betyr «vi la til en nonce og beholdt unsafe-inline for sikkerhets skyld» faktisk at moderne nettlesere håndhever nonce-en. Generatoren flagger kombinasjonen, slik at det blir en beslutning og ikke en tilfeldighet.
strict-dynamic slår av tillatelseslisten. Med strict-dynamic i script-src ignoreres vertskilder, skjemaer, 'self', 'unsafe-inline' og data: for skript; bare nonce og hash teller, og skript de laster inn får laste inn flere skript. Det er det moderne mønsteret for lasterskript — men det gjør resten av script-src-listen dekorativ.
Metataggene er annenrangs.frame-ancestors, report-uri og report-to ignoreres i <meta http-equiv>. Generatoren viser hvilke deler av policyen som stille ikke ville gjelde.
Vanlige feil
Å starte med default-src * pluss en lang liste med unntak. Jobb den andre veien: en stram default-src 'self', og utvid bare direktivene som må utvides. Smale policyer feiler høylytt under testing; brede policyer feiler stille for alltid.
Å levere script-src 'unsafe-inline' 'unsafe-eval' og si at jobben er gjort. En slik policy blokkerer nesten ingenting et XSS-angrep vil gjøre. Gi skriptene nonce eller hash, legg til strict-dynamic, og behold report-only kjørende i produksjon for å fange regresjoner.
Å glemme at default-src ikke dekker alt.base-uri, form-action, frame-ancestors og sandbox har ingen reserveløsning — det mest siterte gapet i virkelige CSP-utrullinger.
Å teste i håndhevingsmodus først. Kjør i Report-Only med en innsamler i en uke, les rapportene, og slå deretter på håndhevingen. En policy som ødelegger kassen er verre enn ingen policy.
Å hashe mellomrom ulikt. En hash dekker de nøyaktige bytene i den innlinjede blokken; et «hjelpsomt» byggetrinn som kutter etterfølgende linjeskift endrer hver hash. Generer hashene fra det som sendes ut, ikke fra kildekoden.
Ofte stilte spørsmål
Trenger jeg default-src hvis jeg lister alle direktivene? Nei, men å beholde den som gulv er god hygiene: nye fetch-direktiver i fremtidige nettlesere faller da tilbake til grunnlinjen i stedet for til «tillatt».
Hva gjør upgrade-insecure-requests egentlig? Den forteller nettleseren å skrive om hver http://-URL siden ville laste — bilder, stiler, forespørsler — til https:// før den sendes. Det er et migreringsverktøy; sluttilstanden er sider uten noen http://-URL i det hele tatt.
Nonce eller hash? Nonce når man kontrollerer serversvaret (en tilfeldig verdi per svar, både i headeren og i hver skriptkode). Hash når HTML-en er statisk eller mellomlagret. Aldri en statisk nonce — en nonce som ikke endrer seg, er bare unsafe-inline med ekstra steg.
Hvorfor kommer ikke brudd fram når policyen er levert? Sjekk om siden er i Report-Only (bare rapporter), om report-uri peker til en innsamler som godtar POST, og om det også er satt opp Reporting-Endpoints / Report-To-mekanismen som det moderne report-to-direktivet krever.
Erstatter en CSP andre beskyttelser? Nei. Den er ett lag: fortsett å escape utdataene, hold informasjonskapsler bak HttpOnly og Secure, behold HSTS. Sjekken av sikkerhetsheadere på denne siden gir karakter til hele settet.
