Websikkerhedsheadere: Content Security Policy (CSP) vs. JavaScript-eksekvering

I det konstant udviklende landskab for websikkerhed er det altafgørende at beskytte dine webapplikationer mod sårbarheder som cross-site scripting (XSS)-angreb. To stærke værktøjer i dit arsenal er Content Security Policy (CSP) og en grundig forståelse af, hvordan JavaScript eksekveres i browseren. Dette blogindlæg vil dykke ned i finesserne ved CSP, udforske dets forhold til JavaScript-eksekvering og give handlingsorienterede indsigter for udviklere og sikkerhedsprofessionelle verden over.

Forståelse af Content Security Policy (CSP)

Content Security Policy (CSP) er en stærk sikkerhedsstandard, der hjælper med at afbøde cross-site scripting (XSS) og andre kodeinjektionsangreb. Den fungerer ved at give dig mulighed for at kontrollere, hvilke ressourcer browseren har tilladelse til at indlæse for en given webside. Tænk på det som en hvidliste for din hjemmesides indhold. Ved at definere en CSP fortæller du i bund og grund browseren, hvilke kilder til indhold (scripts, styles, billeder, skrifttyper osv.) der betragtes som sikre, og hvor de kan stamme fra. Dette opnås gennem brugen af HTTP-svarheadere.

Sådan fungerer CSP

CSP implementeres gennem en HTTP-svarheader ved navn Content-Security-Policy. Denne header indeholder et sæt direktiver, der dikterer, hvilke kilder der er tilladt. Her er nogle nøgledirektiver og deres funktionaliteter:

• default-src: Dette er fallback-direktivet for alle andre hentningsdirektiver. Hvis et mere specifikt direktiv ikke er angivet, bestemmer default-src de tilladte kilder. For eksempel tillader default-src 'self'; ressourcer fra samme oprindelse.
• script-src: Definerer de tilladte kilder for JavaScript-kode. Dette er uden tvivl det mest kritiske direktiv, da det direkte påvirker, hvordan JavaScript-eksekvering kontrolleres.
• style-src: Specificerer de tilladte kilder for CSS-stylesheets.
• img-src: Kontrollerer de tilladte kilder for billeder.
• font-src: Definerer de tilladte kilder for skrifttyper.
• connect-src: Specificerer de tilladte kilder for forbindelser (f.eks. XMLHttpRequest, fetch, WebSocket).
• media-src: Definerer de tilladte kilder for lyd og video.
• object-src: Specificerer de tilladte kilder for plugins som Flash.
• frame-src: Definerer de tilladte kilder for frames og iframes (forældet, brug child-src).
• child-src: Specificerer de tilladte kilder for web workers og indlejret frame-indhold.
• base-uri: Begrænser de URL'er, der kan bruges i et dokuments <base>-element.
• form-action: Specificerer gyldige endepunkter for formularindsendelser.
• frame-ancestors: Specificerer de gyldige forældre, som en side kan indlejres i (f.eks. i en <frame> eller <iframe>).

Hvert direktiv kan tildeles et sæt kildeudtryk. Almindelige kildeudtryk inkluderer:

• 'self': Tillader ressourcer fra samme oprindelse (skema, vært og port).
• 'none': Blokerer alle ressourcer.
• 'unsafe-inline': Tillader inline JavaScript og CSS. Dette frarådes generelt og bør undgås, når det er muligt. Det svækker markant den beskyttelse, CSP tilbyder.
• 'unsafe-eval': Tillader brugen af funktioner som eval(), som ofte bruges i XSS-angreb. Frarådes også kraftigt.
• data:: Tillader data-URL'er (f.eks. base64-kodede billeder).
• blob:: Tillader ressourcer med blob:-skemaet.
• https://example.com: Tillader ressourcer fra det specificerede domæne over HTTPS. Du kan også specificere en bestemt sti, som https://example.com/assets/.
• *.example.com: Tillader ressourcer fra ethvert underdomæne af example.com.

Eksempler på CSP-headere:

Her er nogle eksempler for at illustrere, hvordan CSP-headere bruges:

Eksempel 1: Begrænsning af JavaScript til samme oprindelse

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

              
                Copy
              
            
          

Denne politik tillader browseren kun at eksekvere JavaScript fra samme oprindelse som siden. Dette forhindrer effektivt eksekvering af ethvert JavaScript, der er injiceret fra eksterne kilder. Dette er et godt udgangspunkt for mange hjemmesider.

Eksempel 2: Tilladelse af JavaScript fra samme oprindelse og et specifikt CDN

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

              
                Copy
              
            
          

Denne politik tillader JavaScript fra samme oprindelse og fra domænet cdn.example.com. Dette er almindeligt for hjemmesider, der bruger et CDN (Content Delivery Network) til at levere deres JavaScript-filer.

Eksempel 3: Begrænsning af stylesheets til samme oprindelse og et specifikt CDN

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

              
                Copy
              
            
          

Denne politik begrænser indlæsning af CSS til oprindelsen og cdn.example.com, hvilket forhindrer indlæsning af ondsindede stylesheets fra andre kilder.

Eksempel 4: En mere omfattende politik

            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
              
            
          

Dette er et mere komplekst eksempel, der tillader indhold fra samme oprindelse, JavaScript fra samme oprindelse og et CDN, CSS fra samme oprindelse og Google Fonts, billeder fra samme oprindelse og data-URL'er, og skrifttyper fra Google Fonts. Bemærk, at du eksplicit skal tillade eksterne ressourcer, hvis din side bruger dem.

Håndhævelse af CSP

CSP kan håndhæves på to primære måder:

• Report-Only-tilstand: Du kan indstille Content-Security-Policy-Report-Only-headeren. Denne header blokerer ingen ressourcer, men rapporterer i stedet overtrædelser til et specificeret endepunkt (f.eks. en server, du kontrollerer). Dette er nyttigt til at teste en CSP-politik, før den håndhæves, så du kan identificere potentielle problemer og undgå at ødelægge din hjemmeside. Browseren forsøger stadig at indlæse ressourcerne, men giver en advarsel i udviklerkonsollen og sender en rapport til dit specificerede endepunkt. Rapporten indeholder detaljer om overtrædelsen, såsom kilden til den blokerede ressource og det overtrædende direktiv.
• Håndhævelsestilstand: Når du bruger Content-Security-Policy-headeren, håndhæver browseren aktivt politikken. Hvis en ressource overtræder politikken (f.eks. et script indlæses fra en uautoriseret kilde), vil browseren blokere den. Dette er den tilsigtede og mest effektive måde at bruge CSP til sikkerhed.

JavaScript-eksekvering og CSP

Samspillet mellem CSP og JavaScript-eksekvering er kritisk. CSP's script-src-direktiv er det primære kontrolpunkt for, hvordan JavaScript håndteres. Når en browser støder på JavaScript, tjekker den script-src-direktivet i CSP-headeren. Hvis JavaScript-kilden er tilladt, eksekverer browseren det. Hvis kilden ikke er tilladt, blokeres scriptet, og der genereres en overtrædelsesrapport, hvis rapportering er aktiveret.

Indvirkning på JavaScript-eksekvering

CSP har en betydelig indvirkning på, hvordan du skriver og strukturerer din JavaScript-kode. Specifikt kan det påvirke:

• Inline JavaScript: JavaScript skrevet direkte i <script>-tags i din HTML er ofte begrænset. Brug af 'unsafe-inline' i script-src lemper denne begrænsning, men frarådes kraftigt. En bedre tilgang er at flytte inline JavaScript til eksterne JavaScript-filer.
• eval() og anden dynamisk kodeeksekvering: Funktioner som eval(), setTimeout() med et strengargument og new Function() er ofte begrænsede. Kildeudtrykket 'unsafe-eval' er tilgængeligt, men bør undgås. I stedet bør du omskrive din kode for at undgå disse praksisser eller bruge alternative metoder.
• Eksterne JavaScript-filer: CSP kontrollerer, hvilke eksterne JavaScript-filer der kan indlæses. Dette er et centralt forsvar mod XSS-angreb, der forsøger at injicere ondsindede scripts.
• Event Handlers: Inline event handlers (f.eks. <button onclick="myFunction()"></button>) blokeres ofte, medmindre 'unsafe-inline' er tilladt. Det er bedre praksis at tilknytte event listeners i JavaScript-filer.

Bedste praksis for JavaScript-eksekvering med CSP

For effektivt at bruge CSP og sikre din JavaScript-eksekvering, bør du overveje disse bedste praksisser:

• Undgå inline JavaScript: Flyt al JavaScript-kode til eksterne .js-filer. Dette er det enkeltstående mest effektfulde, du kan gøre.
• Undgå eval() og anden dynamisk kodeeksekvering: Omskriv din kode for at undgå at bruge eval(), setTimeout() med strengargumenter og new Function(). Disse er almindelige angrebsvektorer.
• Brug nonces eller hashes til inline scripts (hvis nødvendigt): Hvis du absolut er nødt til at bruge inline scripts (f.eks. for ældre kode), kan du overveje at bruge en nonce (en unik, tilfældigt genereret streng) eller en hash (en kryptografisk digest af scriptets indhold). Du tilføjer noncen eller hashen til din CSP-header og script-tagget. Dette tillader browseren at eksekvere scriptet, hvis det matcher de specificerede kriterier. Dette er et mere sikkert alternativ end 'unsafe-inline', men det tilføjer kompleksitet.
• Anvend en streng CSP-politik: Start med en restriktiv CSP-politik (f.eks. script-src 'self';) og løsn den gradvist efter behov. Overvåg for overtrædelser ved hjælp af Content-Security-Policy-Report-Only-headeren, før du håndhæver politikken.
• Gennemgå og opdater regelmæssigt din CSP-politik: Din webapplikation vil udvikle sig over tid, og det samme vil din CSP-politik. Gennemgå og opdater din politik regelmæssigt for at sikre, at den fortsat yder tilstrækkelig beskyttelse. Dette inkluderer, når du tilføjer nye funktioner, integrerer tredjepartsbiblioteker eller ændrer din CDN-konfiguration.
• Brug en Web Application Firewall (WAF): En WAF kan hjælpe med at opdage og afbøde angreb, der måtte omgå din CSP. En WAF fungerer som et ekstra forsvarslag.
• Overvej sikkerhed i designet: Implementer sikkerhedsprincipper fra starten af dit projekt, herunder sikre kodningspraksisser og regelmæssige sikkerhedsrevisioner.

CSP i praksis: Eksempler fra den virkelige verden

Lad os se på nogle scenarier fra den virkelige verden, og hvordan CSP hjælper med at afbøde sårbarheder:

Scenarie 1: Forebyggelse af XSS-angreb fra eksterne kilder

En hjemmeside tillader brugere at indsende kommentarer. En angriber injicerer ondsindet JavaScript i en kommentar. Uden CSP ville browseren eksekvere det injicerede script. Med en CSP, der kun tillader scripts fra samme oprindelse (script-src 'self';), vil browseren blokere det ondsindede script, fordi det stammer fra en anden kilde.

Scenarie 2: Forebyggelse af XSS-angreb fra kompromitteret, betroet CDN

En hjemmeside bruger et CDN (Content Delivery Network) til at levere sine JavaScript-filer. En angriber kompromitterer CDN'et og erstatter legitime JavaScript-filer med ondsindede. Med en CSP, der specificerer CDN'ets domæne (f.eks. script-src 'self' cdn.example.com;), er hjemmesiden beskyttet, fordi den begrænser eksekvering til kun filer, der er hostet på det specifikke CDN-domæne. Hvis det kompromitterede CDN bruger et andet domæne, ville browseren blokere de ondsindede scripts.

Scenarie 3: Risikobegrænsning med tredjepartsbiblioteker

En hjemmeside integrerer et tredjeparts JavaScript-bibliotek. Hvis det bibliotek bliver kompromitteret, kan en angriber injicere ondsindet kode. Ved at bruge en streng CSP kan udviklere begrænse eksekveringen af JavaScript fra tredjepartsbiblioteket ved at specificere kildedirektiver i deres CSP-politik. For eksempel, ved at specificere de specifikke oprindelser for tredjepartsbiblioteket, kan hjemmesiden beskytte sig mod potentielle exploits. Dette er især vigtigt for open source-biblioteker, som ofte bruges i mange projekter verden over.

Globale eksempler:

Overvej det mangfoldige digitale landskab i verden. Lande som Indien, med deres store befolkninger og udbredte internetadgang, står ofte over for unikke sikkerhedsudfordringer på grund af det stigende antal tilsluttede enheder. Tilsvarende er sikker webapplikationsudvikling altafgørende i regioner som Europa, med streng overholdelse af GDPR (General Data Protection Regulation). Brug af en CSP og anvendelse af sikre JavaScript-praksisser kan hjælpe organisationer i alle disse regioner med at opfylde deres sikkerheds- og overholdelsesforpligtelser. I lande som Brasilien, hvor e-handel vokser hurtigt, er sikring af onlinetransaktioner med CSP afgørende for at beskytte både virksomheden og forbrugeren. Det samme gælder i Nigeria, Indonesien og alle andre nationer.

Avancerede CSP-teknikker

Ud over det grundlæggende kan flere avancerede teknikker forbedre din CSP-implementering:

• Nonce-baseret CSP: Når du arbejder med inline scripts, giver nonces et mere sikkert alternativ til 'unsafe-inline'. En nonce er en unik, tilfældigt genereret streng, som du genererer for hver anmodning og inkluderer i både din CSP-header (script-src 'nonce-DIN_NONCE';) og <script>-tagget (<script nonce="DIN_NONCE">). Dette fortæller browseren kun at eksekvere scripts, der har den matchende nonce. Denne tilgang begrænser i høj grad mulighederne for angribere til at injicere ondsindet kode.
• Hash-baseret CSP (SRI - Subresource Integrity): Dette giver dig mulighed for at specificere den kryptografiske hash af scriptets indhold (f.eks. ved hjælp af SHA-256-algoritmen). Browseren vil kun eksekvere scriptet, hvis dets hash matcher den i CSP-headeren. Dette er en anden måde at håndtere inline scripts (mindre almindeligt) eller eksterne scripts på. Subresource Integrity bruges generelt til eksterne ressourcer som CSS- og JavaScript-biblioteker, og det beskytter mod risikoen for, at et kompromitteret CDN leverer ondsindet kode, der er forskellig fra det tilsigtede bibliotek.
• CSP Reporting API: CSP Reporting API giver dig mulighed for at indsamle detaljerede oplysninger om CSP-overtrædelser, herunder det overtrædende direktiv, kilden til den blokerede ressource og URL'en på den side, hvor overtrædelsen fandt sted. Disse oplysninger er essentielle for at overvåge, fejlfinde og forbedre din CSP-politik. Flere værktøjer og tjenester kan hjælpe dig med at behandle disse rapporter.
• CSP Builder-værktøjer: Værktøjer kan hjælpe dig med at generere og teste CSP-politikker, såsom CSP Evaluator og online CSP-byggere. Disse kan strømline processen med at oprette og administrere dine politikker.

JavaScript-eksekvering og bedste praksis for sikkerhed

Ud over CSP bør du overveje følgende generelle bedste praksisser for sikkerhed vedrørende JavaScript:

• Inputvalidering og -sanitering: Valider og saniter altid brugerinput på server-siden og klient-siden for at forhindre XSS og andre injektionsangreb. Saniter data for at fjerne eller kode potentielt farlige tegn, såsom dem, der bruges til at starte et script.
• Sikre kodningspraksisser: Følg sikre kodningsprincipper, såsom at bruge parameteriserede forespørgsler for at forhindre SQL-injektion, og undgå at gemme følsomme data i klient-side kode. Vær opmærksom på, hvordan koden håndterer potentielt følsomme data.
• Regelmæssige sikkerhedsrevisioner: Udfør regelmæssige sikkerhedsrevisioner, herunder penetrationstest, for at identificere og rette sårbarheder i dine webapplikationer. En sikkerhedsrevision, også kendt som en penetrationstest, er et simuleret angreb på et system. Disse revisioner er essentielle for at opdage sårbarheder, som angribere kan udnytte.
• Hold afhængigheder opdateret: Opdater regelmæssigt dine JavaScript-biblioteker og -frameworks til de nyeste versioner for at lappe kendte sårbarheder. Sårbare biblioteker er en stor kilde til sikkerhedsproblemer. Brug værktøjer til afhængighedsstyring til at automatisere opdateringer.
• Implementer HTTP Strict Transport Security (HSTS): Sørg for, at din webapplikation bruger HTTPS og implementerer HSTS for at tvinge browsere til altid at oprette forbindelse til dit site over HTTPS. Dette hjælper med at forhindre man-in-the-middle-angreb.
• Brug en Web Application Firewall (WAF): En WAF tilføjer et ekstra lag af sikkerhed ved at filtrere ondsindet trafik og forhindre angreb, der omgår andre sikkerhedsforanstaltninger. En WAF kan opdage og afbøde ondsindede anmodninger, såsom SQL-injektioner eller XSS-forsøg.
• Uddan dit udviklingsteam: Sørg for, at dit udviklingsteam forstår bedste praksis for websikkerhed, herunder CSP, XSS-forebyggelse og sikre kodningsprincipper. At uddanne dit team er en kritisk investering i sikkerhed.
• Overvåg for sikkerhedstrusler: Opsæt overvågnings- og alarmsystemer for at opdage og reagere hurtigt på sikkerhedshændelser. Effektiv overvågning hjælper med at identificere og reagere på potentielle sikkerhedstrusler.

Sammenfatning: En praktisk vejledning

Lad os bygge et forenklet eksempel for at illustrere, hvordan man anvender disse koncepter.

Scenarie: En simpel hjemmeside med en kontaktformular, der bruger JavaScript til at håndtere formularindsendelser.

1. Trin 1: Analyser applikationens afhængigheder: Bestem alle JavaScript-filer, eksterne ressourcer (som CDN'er) og inline scripts, som din applikation bruger. Identificer alle de scripts, der er nødvendige for korrekt funktionalitet.
2. Trin 2: Flyt JavaScript til eksterne filer: Flyt alt inline JavaScript til separate .js-filer. Dette er fundamentalt.
3. Trin 3: Definer en grundlæggende CSP-header: Start med en restriktiv CSP. Hvis du f.eks. bruger samme oprindelse, kan du begynde med følgende:

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

4. Trin 4: Test CSP i Report-Only-tilstand: Implementer Content-Security-Policy-Report-Only-headeren i første omgang for at identificere eventuelle potentielle konflikter. Indsaml rapporterne og analyser dem.
5. Trin 5: Adresser eventuelle overtrædelser: Baseret på rapporterne skal du justere CSP-headeren for at tillade de nødvendige ressourcer. Dette kan indebære hvidlistning af specifikke CDN-domæner eller, hvis det er absolut nødvendigt, brug af nonces eller hashes til inline scripts (selvom dette sjældent er nødvendigt, hvis bedste praksis følges).
6. Trin 6: Udrul og overvåg: Når du er sikker på, at CSP'en fungerer korrekt, skal du skifte til Content-Security-Policy-headeren. Overvåg løbende din applikation for overtrædelser og juster din CSP-politik efter behov.
7. Trin 7: Implementer inputvalidering og -sanitering: Sørg for, at server-side- og klient-side-koden validerer og saniterer brugerinput for at forhindre sårbarheder. Dette er afgørende for at beskytte mod XSS-angreb.
8. Trin 8: Regelmæssige revisioner og opdateringer: Gennemgå og opdater regelmæssigt din CSP-politik, idet du husker på nye funktioner, integrationer og eventuelle ændringer i applikationens arkitektur eller de afhængigheder, den bygger på. Implementer regelmæssige sikkerhedsrevisioner for at fange uforudsete problemer.

Konklusion

Content Security Policy (CSP) er en kritisk komponent i moderne websikkerhed, der arbejder sammen med praksisser for JavaScript-eksekvering for at beskytte dine webapplikationer mod en lang række trusler. Ved at forstå, hvordan CSP-direktiver kontrollerer JavaScript-eksekvering, og ved at overholde bedste praksis for sikkerhed, kan du markant reducere risikoen for XSS-angreb og forbedre den overordnede sikkerhed for dine webapplikationer. Husk at anvende en lagdelt tilgang til sikkerhed, hvor CSP integreres med andre sikkerhedsforanstaltninger som inputvalidering, Web Application Firewalls (WAFs) og regelmæssige sikkerhedsrevisioner. Ved konsekvent at anvende disse principper kan du skabe en mere sikker og tryg weboplevelse for dine brugere, uanset deres placering eller den teknologi, de bruger. At sikre dine webapplikationer beskytter ikke kun dine data, men opbygger også tillid hos dit globale publikum og skaber et ry for pålidelighed og sikkerhed.