Säkerhetsheaders för webbplatser: sätt säkerhetsheaders rätt

Kort sagt: Säkerhetsheaders är webbserverns anvisningar till webbläsaren som skyddar besökare mot angrepp som cross-site scripting, clickjacking och okrypterade förbindelser. De viktigaste är HSTS, Content-Security-Policy, X-Content-Type-Options, skydd mot främmande ramar, Referrer-Policy och Permissions-Policy. De är en meningsfull härdning men ersätter inga uppdateringar på servern.

Vad säkerhetsheaders åstadkommer och vad de inte gör

Vid varje sidanrop skickar webbservern förutom innehållet också headers. Några av dem styr webbläsarens säkerhetsfunktioner. Därmed kan man till exempel fastställa att en sida bara laddas via HTTPS eller att webbläsaren inte kör skript från främmande domäner.

För driftansvariga är bedömningen viktig: Headers skyddar i första hand besökarna, till exempel mot att sessioner snappas upp eller mot manipulerade formulär. De stänger inga sårbarheter på servern. En svaghet i PHP, i CMS:et eller i ett tillägg finns kvar hur väl headers än är satta. I samspel med ren kod begränsar de dock följderna av många fel avsevärt.

De viktigaste säkerhetsheaders i överblick

HSTS bör ni sätta först när alla underdomäner är tillförlitligt nåbara via HTTPS. Webbläsaren minns anvisningen under den angivna tiden; ett fel går då inte att ta tillbaka direkt. Börja vid behov med en kort löptid och öka den efter lyckade tester. Tillvalet preload för permanent in domänen i webbläsartillverkarnas listor och bör sättas först efter noggrann granskning.

Headers är dessutom inte den enda platsen där webbläsaren erbjuder skydd. Cookies bör ha attributen Secure, HttpOnly och SameSite, så att sessioner inte snappas upp via okrypterade förbindelser eller skript. Hur ni ställer in det i PHP beskriver guiden om sessioner.

Sätta säkerhetsheaders i Nginx

I Nginx hör headers hemma i server-blocket för respektive webbplats. Tillägget always ser till att de skickas även på felsidor.

server {
    # ...
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'" always;

    server_tokens off;
}

En egenhet hos Nginx: Sätter ett location-block egna add_header-direktiv tas headers från server-blocket inte över där. Kontrollera därför även undersidor och statiska filer. Ytterligare härdning för den här kombinationen beskriver Skydda Nginx med PHP-FPM.

Sätta säkerhetsheaders i Apache

Under Apache behöver ni modulen mod_headers. Direktiven hör hemma i VirtualHost eller, om åtkomst saknas dit, i .htaccess.

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

ServerTokens Prod
ServerSignature Off

ServerTokens och ServerSignature hör hemma i huvudkonfigurationen. De hindrar servern från att uppge sin exakta version i svar och felsidor. I php.ini uppnår ni samma sak för PHP med expose_php = Off.

Inför Content-Security-Policy stegvis

Content-Security-Policy är den mest verksamma men också mest krävande headern. Den fastställer från vilka källor skript, stilmallar, bilder, typsnitt och ramar får laddas. Laddas ett insmugglat skript från en främmande domän blockerar webbläsaren det.

Moderna webbplatser bäddar ofta in analysverktyg, betalleverantörer, karttjänster eller videor. En för sträng policy lamslår då funktioner. Gå därför fram i steg:

• Börja först med Content-Security-Policy-Report-Only. Webbläsaren rapporterar överträdelser i utvecklarkonsolen eller till en samlingsadress men blockerar ingenting.
• Kartlägg alla källor som behövs och frisläpp dem riktat, i stället för att använda generella jokertecken.
• Lägg ut inline-skript stegvis i filer eller förse dem med nonces, så att man kan avstå från 'unsafe-inline'.
• Växla först efter en testfas utan oväntade rapporter över till Content-Security-Policy.

Kontrollera headers och undvik typiska fel

Efter varje ändring bör ni kontrollera att headers verkligen kommer fram. Det går utan extra verktyg med curl:

# Testa konfigurationen och ladda om
nginx -t && systemctl reload nginx

# Visa headers för startsidan och en statisk fil
curl -sI https://www.example.de/ | grep -iE 'strict|content-security|x-content|x-frame|referrer|permissions|server'
curl -sI https://www.example.de/favicon.ico | grep -iE 'strict|x-content'

Typiska fel är dubbelt satta headers när webbserver och applikation skickar samma headers, ett förkopplat CDN som tar bort eller skriver över headers, och headers som bara syns på startsidan men inte vid omdirigeringar eller felsidor. Kontrollera dessutom efter uppdateringar av CMS:et eller av säkerhetstillägg om headers har ändrats.

Bestäm därför ett ställe där headers underhålls, helst webbservern eller den förkopplade tjänsten. Många CMS-tillägg erbjuder också inställningar för säkerhetsheaders. Det är bekvämt men leder lätt till dubbla eller motstridiga uppgifter om servern dessutom sätter headers. För enskilda tester passar även webbläsarens utvecklarverktyg: På nätverksfliken ser ni svarsheaders för varje förfrågan, och konsolen visar överträdelser av Content-Security-Policy.

Hur hjälper PHP SOS konkret?

• Vi granskar de aktuella headerna för alla era webbplatser, även bakom CDN och proxy, och pekar ut luckor och motsägelser.
• Vi sätter headers centralt i webbservern inom ramen för serverhärdningen och testar startsida, undersidor och felsidor.
• Vi inför Content-Security-Policy i report-only-läge, utvärderar rapporterna och aktiverar den efter samråd.
• Där kodändringar inte är möjliga direkt kompletterar vi skyddet med WAF-regler och virtuell patchning.

Vanliga frågor

Källor

• OWASP Cheat Sheet Series (HTTP Headers)
• OWASP Top 10
• BSI: rekommendationer för webbservrar