Säkerhetsrubriker för Frontend: Bemästra Content Security Policy (CSP)

I dagens digitala landskap, där webbapplikationer blir allt mer komplexa och sammankopplade, är skyddet mot säkerhetshot av yttersta vikt. Medan backend-säkerhet ofta får stor uppmärksamhet, är frontend-säkerhet lika avgörande. Säkerhetsrubriker för frontend fungerar som den första försvarslinjen och ger en mekanism för att instruera webbläsaren om hur den ska bete sig och skydda användare från olika attacker. Bland dessa rubriker utmärker sig Content Security Policy (CSP) som ett kraftfullt verktyg för att mildra ett brett spektrum av risker.

Vad är säkerhetsrubriker för frontend?

Säkerhetsrubriker för frontend är HTTP-svarshuvuden som en webbserver skickar till webbläsaren. Dessa rubriker innehåller instruktioner om hur webbläsaren ska hantera innehållet den tar emot. De hjälper till att förhindra vanliga attacker som:

• Cross-Site Scripting (XSS): Injektion av skadliga skript på betrodda webbplatser.
• Clickjacking: Lura användare att klicka på något annat än vad de uppfattar.
• Man-in-the-Middle-attacker: Avlyssning av kommunikationen mellan användaren och servern.

Några av de viktigaste säkerhetsrubrikerna för frontend inkluderar:

• Content Security Policy (CSP): Definierar de källor från vilka webbläsaren får ladda resurser.
• Strict-Transport-Security (HSTS): Tvingar webbläsaren att använda HTTPS för all kommunikation med webbplatsen.
• X-Frame-Options: Förhindrar att webbplatsen bäddas in i en iframe, vilket mildrar clickjacking-attacker.
• X-XSS-Protection: Aktiverar webbläsarens inbyggda XSS-filter. (Obs: Ofta ersatt av CSP men kan fortfarande ge ett extra skyddslager).
• Referrer-Policy: Kontrollerar mängden referrer-information som skickas med förfrågningar.
• Feature-Policy (nu Permissions-Policy): Låter utvecklare selektivt aktivera och inaktivera webbläsarfunktioner och API:er.

En djupdykning i Content Security Policy (CSP)

Content Security Policy (CSP) är en HTTP-svarshuvud som kontrollerar vilka resurser användaragenten får ladda för en given sida. Den vitlistar i huvudsak källor för godkänt innehåll, vilket avsevärt minskar risken för XSS-attacker. Genom att explicit definiera ursprunget från vilket resurser som skript, stilmallar, bilder och typsnitt kan laddas, gör CSP det mycket svårare för angripare att injicera skadlig kod på din webbplats.

Hur CSP fungerar

CSP fungerar genom att förse webbläsaren med en lista över godkända källor för olika typer av innehåll. När webbläsaren stöter på en resurs som bryter mot CSP, blockerar den resursen och rapporterar överträdelsen. Denna blockeringsmekanism förhindrar att skadlig kod exekveras, även om en angripare lyckas injicera den i HTML-koden.

CSP-direktiv

CSP-direktiv är kärnkomponenterna i en CSP-policy. De specificerar de tillåtna källorna för olika typer av resurser. Några av de vanligaste direktiven inkluderar:

• default-src: Anger standardkällan för alla resurstyper. Detta är ett reservdirektiv som tillämpas när andra mer specifika direktiv inte är definierade.
• script-src: Specificerar de tillåtna källorna för JavaScript.
• style-src: Specificerar de tillåtna källorna för CSS-stilmallar.
• img-src: Specificerar de tillåtna källorna för bilder.
• font-src: Specificerar de tillåtna källorna för typsnitt.
• media-src: Specificerar de tillåtna källorna för ljud och video.
• object-src: Specificerar de tillåtna källorna för plugins som Flash. (Generellt bäst att undvika att tillåta plugins om möjligt).
• frame-src: Specificerar de tillåtna källorna för ramar (iframes).
• connect-src: Specificerar de tillåtna källorna för nätverksförfrågningar (AJAX, WebSockets).
• base-uri: Begränsar de URL:er som kan användas i ett <base>-element.
• form-action: Begränsar de URL:er som formulär kan skickas till.
• frame-ancestors: Specificerar giltiga föräldrar som får bädda in en sida med <frame>, <iframe>, <object>, <embed>, eller <applet>. Detta direktiv ger skydd mot Clickjacking.
• upgrade-insecure-requests: Instruerar användaragenter att behandla alla en webbplats osäkra URL:er (laddade över HTTP) som om de har ersatts med säkra URL:er (laddade över HTTPS). Detta direktiv är avsett för webbplatser som håller på att migrera från HTTP till HTTPS.
• report-uri: Specificerar en URL till vilken webbläsaren ska skicka rapporter om CSP-överträdelser. Föråldrad till förmån för `report-to`.
• report-to: Specificerar ett gruppnamn definierat i ett `Report-To`-huvud. Detta möjliggör mer finkornig kontroll över rapportering, inklusive att specificera flera rapporteringsslutpunkter.

CSP-källvärden

Källvärden definierar ursprunget från vilket resurser får laddas. Några vanliga källvärden inkluderar:

• *: Tillåter innehåll från vilken källa som helst (Undvik att använda detta i produktion!).
• 'self': Tillåter innehåll från samma ursprung (schema, värd och port) som det skyddade dokumentet.
• 'none': Tillåter inte innehåll från någon källa.
• 'unsafe-inline': Tillåter användning av inline JavaScript och CSS (Undvik att använda detta i produktion!).
• 'unsafe-eval': Tillåter användning av dynamisk kodutvärdering (t.ex. eval(), Function()) (Undvik att använda detta i produktion!).
• 'strict-dynamic': Specificerar att det förtroende som explicit ges till ett skript i markupen, genom att det åtföljs av en nonce eller hash, ska propageras till alla skript som laddas av den förfadern.
• 'unsafe-hashes': Tillåter specifika inline-händelsehanterare. Detta avråds generellt på grund av dess komplexitet och begränsade nytta.
• data:: Tillåter laddning av resurser från data-URL:er (t.ex. inbäddade bilder). Använd med försiktighet.
• mediastream:: Tillåter att `mediastream:` URI:er används som mediakälla.
• blob:: Tillåter att `blob:` URI:er används som mediakälla.
• filesystem:: Tillåter att resurser laddas från ett filsystem.
• https://example.com: Tillåter innehåll från en specifik domän och port.
• *.example.com: Tillåter innehåll från valfri subdomän till example.com.
• nonce-{random-value}: Tillåter skript eller stilar med ett matchande nonce-attribut. Detta kräver serversidig generering av ett slumpmässigt nonce-värde för varje förfrågan.
• sha256-{hash-value}: Tillåter skript eller stilar med en matchande SHA256-, SHA384- eller SHA512-hash.

CSP-lägen: Tvingande vs. Endast rapportering

CSP kan distribueras i två lägen:

• Tvingande läge: I detta läge blockerar webbläsaren alla resurser som bryter mot CSP. Detta är det rekommenderade läget för produktionsmiljöer. CSP:n skickas med `Content-Security-Policy`-huvudet.
• Endast rapporteringsläge: I detta läge rapporterar webbläsaren CSP-överträdelser men blockerar inte resurserna. Detta är användbart för att testa och utvärdera en CSP innan den tillämpas. CSP:n skickas med `Content-Security-Policy-Report-Only`-huvudet.

Implementera CSP: En steg-för-steg-guide

Att implementera CSP kan verka avskräckande, men genom att följa ett strukturerat tillvägagångssätt kan du effektivt säkra din webbapplikation.

1. Börja med en policy för endast rapportering

Börja med att distribuera en CSP i endast rapporteringsläge. Detta låter dig övervaka överträdelser utan att störa din webbplats funktionalitet. Konfigurera `report-uri`- eller `report-to`-direktivet för att skicka överträdelsrapporter till en angiven slutpunkt.

Exempelrubrik (Endast rapportering): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. Analysera överträdelsrapporterna

Analysera noggrant överträdelsrapporterna för att identifiera vilka resurser som blockeras och varför. Detta hjälper dig att förstå din webbplats resursberoenden och identifiera potentiella säkerhetssårbarheter.

Överträdelsrapporter skickas vanligtvis som JSON-nyttolaster till den konfigurerade `report-uri`- eller `report-to`-slutpunkten. Dessa rapporter innehåller information om överträdelsen, såsom den blockerade URI:n, det överträdda direktivet och dokumentets URI.

3. Förfina CSP-policyn

Baserat på överträdelsrapporterna, förfina din CSP-policy för att tillåta legitima resurser samtidigt som du bibehåller en stark säkerhetsposition. Lägg till specifika källvärden för de resurser som blockeras. Överväg att använda nonces eller hashar för inline-skript och -stilar för att undvika att använda 'unsafe-inline'.

4. Övergå till tvingande läge

När du är säker på att din CSP-policy inte blockerar legitima resurser, övergå till tvingande läge. Detta kommer att blockera alla återstående överträdelser och ge ett robust säkerhetsskikt mot XSS-attacker.

Exempelrubrik (Tvingande): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. Övervaka och underhåll CSP-policyn

CSP är inte en "ställ in och glöm"-lösning. Det är viktigt att kontinuerligt övervaka din CSP-policy och uppdatera den i takt med att din webbplats utvecklas och nya säkerhetshot dyker upp. Granska regelbundet överträdelsrapporter och justera policyn vid behov.

Praktiska CSP-exempel

Låt oss titta på några praktiska CSP-exempel för olika scenarier:

Exempel 1: Grundläggande CSP för en enkel webbplats

Denna CSP tillåter innehåll från samma ursprung och tillåter bilder från vilken källa som helst.

Content-Security-Policy: default-src 'self'; img-src *

Exempel 2: CSP med specifika skript- och stilkällor

Denna CSP tillåter skript från samma ursprung och från ett specifikt CDN, och stilar från samma ursprung samt inline-stilar.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

Exempel 3: CSP med nonces för inline-skript

Denna CSP kräver en unik nonce för varje inline-skript.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

Viktigt: Nonce-värdet måste genereras dynamiskt på servern för varje förfrågan. Detta förhindrar angripare från att återanvända nonce.

Exempel 4: CSP som begränsar frame-ancestors för att förhindra Clickjacking

Denna CSP förhindrar att sidan bäddas in i en iframe på någon annan domän än `https://example.com`.

Content-Security-Policy: frame-ancestors 'self' https://example.com

Exempel 5: En mer restriktiv CSP med 'strict-dynamic' och en reserv till 'self'

Denna CSP utnyttjar `strict-dynamic` för moderna webbläsare samtidigt som den stöder äldre webbläsare som inte har stöd för det. Den inkluderar också en `report-uri` för att övervaka överträdelser.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Kom ihåg att ersätta `{random-nonce}` med ett dynamiskt genererat nonce-värde på serversidan.

CSP och Single-Page Applications (SPA)

Att implementera CSP i SPA:er kan vara utmanande på grund av dessa applikationers dynamiska natur. SPA:er förlitar sig ofta mycket på JavaScript för att generera och manipulera DOM, vilket kan leda till CSP-överträdelser om det inte hanteras noggrant.

Här är några tips för att implementera CSP i SPA:er:

• Undvik 'unsafe-inline' och 'unsafe-eval': Dessa direktiv bör undvikas när det är möjligt i SPA:er. De försvagar säkerheten i din applikation avsevärt.
• Använd Nonces eller Hashar: Använd nonces eller hashar för inline-skript och -stilar. Detta är den rekommenderade metoden för SPA:er.
• Överväg Trusted Types: Trusted Types är ett webbläsar-API som hjälper till att förhindra DOM-baserade XSS-sårbarheter. Det kan användas tillsammans med CSP för att ytterligare förbättra säkerheten.
• Använd ett CSP-kompatibelt ramverk: Vissa frontend-ramverk (som React med specifika konfigurationer, Angular och Vue.js) erbjuder funktioner som hjälper dig att implementera CSP enklare.

Andra viktiga säkerhetsrubriker för frontend

Medan CSP är en hörnsten i frontend-säkerhet, spelar andra rubriker en avgörande roll för att tillhandahålla en heltäckande försvarsstrategi:

Strict-Transport-Security (HSTS)

Strict-Transport-Security (HSTS)-huvudet instruerar webbläsaren att alltid använda HTTPS för att ansluta till webbplatsen. Detta förhindrar man-in-the-middle-attacker som försöker nedgradera anslutningen till HTTP.

Exempelrubrik: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: Specificerar varaktigheten (i sekunder) som webbläsaren ska komma ihåg att endast ansluta till webbplatsen via HTTPS. Ett värde på 31536000 sekunder (1 år) rekommenderas för produktionsmiljöer.
• includeSubDomains: Indikerar att HSTS-policyn gäller för alla subdomäner till domänen.
• preload: Tillåter att domänen inkluderas i en lista över HSTS-aktiverade domäner som förladdas i webbläsare. Detta kräver att du skickar in din domän till HSTS-förladdningslistan som underhålls av Google.

X-Frame-Options

X-Frame-Options-huvudet förhindrar clickjacking-attacker genom att kontrollera om webbplatsen kan bäddas in i en iframe.

Exempelrubrik: X-Frame-Options: DENY

Möjliga värden:

• DENY: Förhindrar att sidan visas i en iframe, oavsett ursprung.
• SAMEORIGIN: Tillåter att sidan visas i en iframe endast om iframens ursprung matchar sidans ursprung.
• ALLOW-FROM uri: Tillåter att sidan visas i en iframe endast om iframens ursprung matchar den angivna URI:n. Obs: Detta alternativ är föråldrat och stöds kanske inte av alla webbläsare.

Obs: frame-ancestors-direktivet i CSP erbjuder ett mer flexibelt och kraftfullt sätt att kontrollera inramning och föredras generellt framför X-Frame-Options.

X-XSS-Protection

X-XSS-Protection-huvudet aktiverar webbläsarens inbyggda XSS-filter. Även om CSP är en mer robust lösning för att förhindra XSS-attacker, kan detta huvud ge ett extra skyddslager, särskilt för äldre webbläsare som kanske inte har fullt stöd för CSP.

Exempelrubrik: X-XSS-Protection: 1; mode=block

• 1: Aktiverar XSS-filtret.
• 0: Inaktiverar XSS-filtret.
• mode=block: Instruerar webbläsaren att blockera sidan om en XSS-attack upptäcks.
• report=uri: Specificerar en URL dit webbläsaren ska skicka en rapport om en XSS-attack upptäcks.

Referrer-Policy

Referrer-Policy-huvudet kontrollerar mängden referrer-information som skickas med förfrågningar. Referrer-information kan användas för att spåra användare över webbplatser, så att kontrollera den kan förbättra användarnas integritet.

Exempelrubrik: Referrer-Policy: strict-origin-when-cross-origin

Några vanliga värden:

• no-referrer: Skicka aldrig Referer-huvudet.
• no-referrer-when-downgrade: Skicka inte Referer-huvudet till ursprung utan TLS (HTTPS).
• origin: Skicka endast ursprunget (schema, värd och port) i Referer-huvudet.
• origin-when-cross-origin: Skicka ursprunget för förfrågningar mellan olika ursprung och hela URL:en för förfrågningar från samma ursprung.
• same-origin: Skicka Referer-huvudet för förfrågningar från samma ursprung, men inte för förfrågningar mellan olika ursprung.
• strict-origin: Skicka endast ursprunget när protokollsäkerhetsnivån förblir densamma (HTTPS till HTTPS), men skicka inget huvud till en mindre säker destination (HTTPS till HTTP).
• strict-origin-when-cross-origin: Skicka ursprunget när en förfrågan görs från samma ursprung. För förfrågningar mellan olika ursprung, skicka ursprunget endast när protokollsäkerhetsnivån förblir densamma (HTTPS till HTTPS), men skicka inget huvud till en mindre säker destination (HTTPS till HTTP).
• unsafe-url: Skicka hela URL:en i Referer-huvudet, oavsett ursprung. Använd med yttersta försiktighet, eftersom detta kan exponera känslig information.

Permissions-Policy (tidigare Feature-Policy)

Permissions-Policy-huvudet (tidigare känt som Feature-Policy) låter utvecklare selektivt aktivera och inaktivera webbläsarfunktioner och API:er. Detta kan hjälpa till att minska applikationens attackyta och förbättra användarnas integritet.

Exempelrubrik: Permissions-Policy: geolocation=()

Detta exempel inaktiverar geolokaliserings-API:et för webbplatsen.

Andra funktioner som kan kontrolleras med Permissions-Policy inkluderar:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

Ställa in säkerhetsrubriker på olika plattformar

Metoden för att ställa in säkerhetsrubriker varierar beroende på vilken webbserver eller plattform du använder. Här är några vanliga exempel:

Apache

Du kan ställa in säkerhetsrubriker i Apache genom att lägga till dem i .htaccess-filen eller serverns konfigurationsfil (httpd.conf).

Exempel på .htaccess-konfiguration:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Du kan ställa in säkerhetsrubriker i Nginx genom att lägga till dem i serverblocket i Nginx-konfigurationsfilen (nginx.conf).

Exempel på Nginx-konfiguration:

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

Du kan ställa in säkerhetsrubriker i Node.js med hjälp av middleware som Helmet.

Exempel med Helmet:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Customize CSP if needed
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

Cloudflare låter dig ställa in säkerhetsrubriker med deras Page Rules eller Transform Rules.

Testa dina säkerhetsrubriker

Efter att ha implementerat säkerhetsrubriker är det avgörande att testa dem för att säkerställa att de fungerar korrekt. Flera onlineverktyg kan hjälpa dig att analysera din webbplats säkerhetsrubriker:

• SecurityHeaders.com: Ett enkelt och effektivt verktyg för att analysera säkerhetsrubriker.
• Mozilla Observatory: Ett omfattande verktyg för att testa webbplatssäkerhet, inklusive säkerhetsrubriker.
• WebPageTest.org: Låter dig se HTTP-huvudena i vattenfallsdiagrammet.

Slutsats

Säkerhetsrubriker för frontend, särskilt Content Security Policy (CSP), är avgörande för att skydda webbapplikationer från olika attacker och förbättra användarsäkerheten. Genom att noggrant implementera och underhålla dessa rubriker kan du avsevärt minska risken för XSS, clickjacking och andra säkerhetssårbarheter. Kom ihåg att börja med en policy för endast rapportering, analysera överträdelsrapporterna, förfina policyn och sedan övergå till tvingande läge. Övervaka och uppdatera regelbundet dina säkerhetsrubriker för att hålla din webbplats säker i takt med att den utvecklas och nya hot dyker upp.

Genom att anamma ett proaktivt förhållningssätt till frontend-säkerhet kan du bygga säkrare och mer pålitliga webbapplikationer som skyddar dina användare och ditt företag.