Styrk sikkerheden i WP 6.4 med HTTP Security Headers

Sikring af websites er nørdet og måske er det svært at se hvad du umiddelbart får ud af indsatsen. Men bliver dit site misbrugt, risikerer du både at skade virksomhedens omdømme.

Så du har tunet performance, SEO og webtilgængelighed, Google Lighthouse i DevTools kvitterer med fanfarer og konfetti, og du læner dig velfortjent tilbage. Og så får du den idé, at tjekke dit site på webpagetest.org

Det kan jo aldrig skade med en “second opinion”, vel?

Hvis du kæmper dig igennem artiklen her, bliver du klædt på til at vende dit websites Security Score, fra et blodrødt Forkasteligt til et lysegrønt Alletiders.

WebPageTest.org efter screenshot
Du kan forbedre din security score fra F til A på et par timer inklusive grundig test.

Hvad mangler et site med en ringe security-score?

Det som WebPageTest.org og andre tjenester påpeger – hvis dit WordPress site ligner de flestes – er manglende HTTP Security Headers Disse er en slags regler, eller politikker, der fortæller din browser hvordan dit website skal opføre sig, hvad dit website må, og i særdeleshed hvad det ikke må. Det kan fx være krav om, at al kommunikation til og fra dit website skal være krypteret, og at dit website ikke må afvikle kode fra andre websites.

Olsenbanden bryder ind på De Kongelige Teater

Tænk på det som at du ud over at låse hoveddøren, også lægger dine værdifulde ejendele i pengeskabet. Hvis nogen bryder ind i huset, har du gjort arbejdet ekstra surt for indbrudstyven.

Med HTTP Security Headers på plads, er der en reduceret risiko for at dit site kompromitteres, og skulle det alligevel ske, er mulighederne for at misbrug stærkt begrænsede.

Hvad denne artikel ikke handler om

Jeg går ud fra, at du allerede har et SSL-certifikat på dit website, så det kommer jeg ikke ind på her. Jeg viser dog hvordan du kan sikre at certifikatet benyttes, når nu du alligevel er i gang med at redigere din .htaccess-fil.

Andre gode idéer til sikring af dit WordPress-website omhandler firewalls og 2-faktor login, brugerrettigheder, backup og oppetidsovervågning. Vil du læse mere om disse emner, så skriv gerne en kommentar nederst på siden.

Security Headers by Probely

Hos Probely får du et nemt overblik over de “rå headers” og deres indstillinger. Probely et af de få steder der tjekker for den nye og stadigt ikke så udbredte Content Security Policy og ikke bare om den er til stede, men også hvordan den er konfigureret.

The HTTP response headers that this site analyses provide huge levels of protection and it’s important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

securityheaders.com

Mozilla Observatory

Den anden tjeneste jeg anbefaler er Mozilla Observatory. Her får du helt konkrete anbefalinger til forbedrede indstillinger, og tjenesten har den mest omfattende “Content Security Policy analysis”, som afslører ikke bare om, men også hvordan du har konfigureret CSP. Det er også den mest tekniske tjeneste, hvorfor jeg mener at Probely også har sin berettigelse. På den måde kan du komme i gang med at sikre dit website, uden at modet helt tages fra dig 🙂

The scores and grades offered by the Mozilla Observatory are designed to alert developers when they’re not taking advantage of the latest web security features, as recommended in Mozilla’s web security guidelines and server side TLS guidelines. Individual developers will need to determine which of these security technologies is right for their sites.

observatory.mozilla.org

Hardenize

Endelig er der Hardenize, som tjekker dit domænes sikkerhed i bred forstand. Tjekket omfatter både opsætningen af selve domænet, email-services (SPF, DMARC osv) samt selve websitet inklusive de den lidt specielle HSTS Preloading. Hardenize har også ret fine anbefalinger til hvordan du forbedrer sikkerheden på dit website.

With so many security features to deploy and network services to configure, everybody needs help to understand what their networks look like.

hardenize.com

Sådan tilføjer du HTTP security headers til dit website

Du skal bruge en Apache eller LiteSpeed webserver

Tipsene her på siden, tager udgangspunkt i at du har en Apache-webserver eller varianten LiteSpeed, og at du har adgang til at redigere .htaccess-filen, enten via dit webhotels kontrolpanel, FTP eller et plugin som den glimrende Htaccess File Editor.

Tag backup – og afprøv én header ad gangen

Lad nu være med hovedløst at smide samtlige headers ind på din trafikerede webshop, på en lønningsdag. Prøv dem lige af på et testsite og bliv fortrolig med processen. Tag en backup. Da du blot laver ændringer i .htaccess-filen, som er en simpel tekstfil, kan du fx kopiere hele det eksisterende indhold til notepad, inden du går i gang.

Redigering af .htaccess med Htaccess File Editor

Benytter du pluginet Htaccess File Editor, kan du redigere .htaccess-filer direkte i dit WordPress Dashboard.

WP Htaccesse Editor screenshot med knappen "Test Before Saving" fremhævet
I WP Htaccess Editor kan man teste for syntax-fejl inden man gemmer.

Husk at læse afsnittet “Read carefully” inden du går i gang. Og brug knappen Test Before Saving før du gemmer. Funktionen kan fange visse syntax-fejl, men er ingen garanti.

Tjek om det virker

Sådan tjekker du hurtigt om en den tilføjede sercurity header er tråd i kraft:

  1. Åbn Developer Tools
  2. Vælg fanen Network
  3. Vælg dit domæne i kolonnen Name
  4. Kig under Response Headers. Kan du finde din nye header?

Det er også altid en god idé, løbende at tjekke fanen Console for eventuelle fejlmeddelelser.

HTTP Response Header in developer tools

Automatisk 301 redirect til https (SSL/TLS-kryptering)

Hvis du i forvejen har automatisk redirect fra http til https, f.eks. med det gratis plugin Really Simple SSL, behøver du ikke nedenstående stump kode. De gør præcis det samme. Men vælger du at implementere en eller flere af de anbefalede security headers og er derfor alligevel i gang med at redigere i din .htaccess-fil, kan du bruge stumpen her, og slippe afsted med ét plugin mindre i din WordPress-installation.

There are times when we need to tell users that a resource has moved, either temporarily or permanently. This is what we use Redirect and RedirectMatch for.

Apache Configuration: .htaccess
# Automatic 301 redirect to https
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

Anbefalede HTTP Security Headers – de otte nemme

Herunder finder du de headers du lettest implementerer. Ved hver header finder du en kort beskrivelse, et link til uddybende information, samt en kodeblok du kan paste ind i .htaccess. Linjen med hash-tagget # opfattes blot som en kommentar af serveren, så den kan du vælge at undlade.

Jeg har valgt ikke at kaste mig ud i et forsøg på at fordanske beskrivelserne af den enkelte header – det kan være svært nok at forstå i forvejen. I stedet er beskrivelserne citeret fra den linkede dokumentation, primært MDN Web Docs

X Frame Options

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

X Frame Options dokumentation
# X Frame Options
Header always set X-Frame-Options "SAMEORIGIN"

X XSS Protection (deprecated)

Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

X XSS Protection dokumentation
# X XSS-Protection (deprecated)
Header set X-XSS-Protection "0"

X-Content-Type-Options

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured.

X Content Type Options dokumentation
#  X Content-Type-Options
Header set X-Content-Type-Options "nosniff"

X Permitted Cross Domain Policies

Specifies if a cross-domain policy file (crossdomain.xml) is allowed. The file may define a policy to grant clients, such as Adobe’s Flash Player (now obsolete), Adobe Acrobat, Microsoft Silverlight (now obsolete), or Apache Flex, permission to handle data across domains that would otherwise be restricted due to the Same-Origin Policy.

X Permitted Cross Domain Policies dokumentation
# X Permitted Cross Domain Policies
Header set X-Permitted-Cross-Domain-Policies "none"

X-Powered-By and Server

May be set by hosting environments or other frameworks and contains information about them while not providing any usefulness to the application or its visitors. Unset this header to avoid exposing potential vulnerabilities.

X-Powered-By
# Remove Unwanted HTTP Response Headers (Litespeed + PHP)
Header unset X-Powered-By
Header unset Server

HTTP Strict Transport Security (HSTS)

If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types http://www.foo.com/ or even just foo.com. This creates an opportunity for a man-in-the-middle attack. The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.

Strict Transport Security documentation
# Strict Transport Security
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS 

Referrer Policy

The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML.

Referrer Policy dokumentation
# Referrer Policy 
Header set Referrer-Policy "strict-origin-when-cross-origin"

Expect-CT (deprecated)

Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible.

Expect-CT dokumentation
# Expect-CT (deprecated)
# Header set Expect-CT "max-age=86400, enforce" env=HTTPS

Fire extra avancerede politikker

Nu begynder det at blive en lille smule speget, og du skal kun implementere de følgende politikker hvis du har god tid. Politikkers effektivitet, især Content Security Policy, afhænger stærkt af om de er korrekt tilpasset netop dit website. Fortæller man, at et website fx ikke må anvende mikrofonen, ja så vil mikrofonen selvsagt ikke virke på sitet, og var det egentlig meningen at den skulle det, ja så står sikkerheden jo i vejen for funktionaliteten.

Bye bye Feature-Policy, hello Permissions-Policy

HTTP Toolkit

Desuden er nogle af politikkerne under ombygning og endnu sparsomt understøttet af alle browsere. Så jeg har valgt nogle politikker som er – for begyndere om man vil. De strammer stadigt op sammenlignet med ikke at have politikkerne implementeret, de er afprøvet på flere forskellige sites, og de fungerer som et godt udgangspunkt for mere minutiøs gennemgang, hvis du en dag ønsker at stramme yderligere op.

Igen, test dit site grundigt efter implementering – og knækker filmen, så nøjes med at implementere én politik ad gangen, så du kan se hvor det eventuelt går galt.

Feature Policy

Feature Policy allows web developers to selectively enable, disable, and modify the behavior of certain features and APIs in the browser. It is similar to Content Security Policy but controls features instead of security behavior.

Feature Policy dokumentation
# Feature Policy (rudimentary policies supported by most browsers)
Header set Feature-Policy "microphone 'none'; camera 'none'"

Permissions Policy

Permissions Policy is a web platform API which gives a website the ability to allow or block the use of browser features in its own frame or in iframes that it embeds.

Permissions Policy dokumentation
# Permissions Policy (rudimentary policies supported by chrome and FF)
Header set Permissions-Policy "autoplay=(self), encrypted-media=(self), fullscreen=(self), geolocation=(self), midi=(self), payment=(self)"

Content Security Policy

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Content Security Policy dokumentation

For at fungere uden problemer under WordPress 6.3 og de plugins du måtte anvende, er nedenstående CSP ret løs – blot en smule bedre end ingenting. For rigtig at få fuld glæde af CSP’en bør den tilrettes netop dit site. Der er udmærkede ekstensions både til Firefox og Chrome, som kan hjælpe hermed, og værktøjer til at verificere syntaksen på din policy, som – indrømmet – kan være temmelig kringlet.

# Content Security Policy (CSP - quite lax WP 6.3 compatible policies)
Header set Content-Security-Policy "default-src 'self' https:; object-src 'none'; style-src 'self' https: 'unsafe-inline'; font-src 'self' https: data:; img-src 'self' https: data: blob:; frame-src 'self' https: blob:; script-src 'self' https: data: blob: 'unsafe-inline' 'unsafe-eval';"

ForceSecureCookie

As of LSWS v 5.4.9 build 2, a new directive ForceSecureCookie has been introduced to enforce secure , SameSite and httponly cookie attributes

LiteSpeed Alternative to Apache Header Edit
## ForceSecureCookie (LiteSpeed Set Cookie HTTPOnly Secure alternative)
<IfModule LiteSpeed>
	ForceSecureCookie same_site_strict
</IfModule>

Den samlede kode til din .htacess-fil.

Herunder er den samlede kode jeg benytter på alle mine sites, inklusive SSL redirect-stumpen, de otte enkle politikker og de fire avancerede, lige til at sætte ind i toppen af .htaccess. Og jeg siger det lige igen: husk backup og test 🙂

### BEGIN Improved Site Security 2023 by oldrup.dk - 2023-09-28

## Automatic 301 redirect to https

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

## Additional security headers

<ifModule mod_headers.c>

# X Frame Options
Header always set X-Frame-Options "SAMEORIGIN"

# X XSS-Protection (deprecated)
Header set X-XSS-Protection "0"

#  X Content-Type-Options
Header set X-Content-Type-Options "nosniff"

# X Permitted Cross Domain Policies
Header set X-Permitted-Cross-Domain-Policies "none"

# X-Powered-By and Server
Header unset X-Powered-By
Header unset Server

# Enable Strict Transport Security
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS 

# Referrer Policy 
Header set Referrer-Policy "strict-origin-when-cross-origin"

## Advanced policies - basic implementation

# Feature Policy (rudimentary policies supported by most browsers)
Header set Feature-Policy "microphone 'none'; camera 'none'"

# Permissions Policy (rudimentary policies supported by chrome and FF)
Header set Permissions-Policy "autoplay=(self), encrypted-media=(self), fullscreen=(self), geolocation=(self), midi=(self), payment=(self)"

# Content Security Policy (CSP - quite lax WP 6.3 compatible policies)
Header set Content-Security-Policy "default-src 'self' https:; object-src 'none'; style-src 'self' https: 'unsafe-inline'; font-src 'self' https: data:; img-src 'self' https: data: blob:; frame-src 'self' https: blob:; script-src 'self' https: data: blob: 'unsafe-inline' 'unsafe-eval';"

</IfModule>

## ForceSecureCookie (LiteSpeed Set Cookie HTTPOnly Secure alternative)
<IfModule LiteSpeed>
	ForceSecureCookie same_site_strict
</IfModule>

### END Improved Site Security 2023

Opdatering med WordPress 6.3

Den seneste version af WordPress inkluderer nogle ret fine features. Nu kan du selv oprette og indsætte dine egne “block patterns”. Det er ret praktisk. Under block-editorens kølerhjelm, finder vi “blobs” og “frames”, så hvis vores Content Security Policy ikke tillader dette, ja så kan vi ikke finde vores friskbagte block patterns.

Derfor, og for at sikre en større kompatibilitet med de plugins jeg typisk ser anvendt, har jeg tilrettet CSP’en her, så den er lidt mere medgørlig, og vi nu kan benytte os af de nye funktioner i WordPerss 6.3. Så har du brugt koden her på siden før, så bør du kigge på om det vil give mening for dig at opdatere den. Jeg modtager gerne feedback. Sikre WordPress websites er i alles interesse.

Opsummering

Tag det fra én der har prøvet begge dele; det er langt mindre tidskrævende at forebygge – end at rydde op efter et hackerangreb.

Hvad gør du for at sikre dine websites? Kunne du bruge forslagene her i artiklen til noget, og er det et emne du gerne vil læse mere om? Så efterlad gerne en kommentar herunder.

Tak for at du holdt ved så længe 🙂

Read more about Bjarne Oldrup, Sønderborg

Bjarne Oldrup

Bjarne er webudvikler med en stor forkærlighed for det bæredygtige, inkluderende og respektfulde internet.

Med en baggrund som datatekniker i 1992, har han arbejdet som programmør, sysadmin og netværksspecialist. I dag fokuserer han på hjemmesiders klimaaftryk, webtilgængelighed og GDPR-compliance.

WordPress, HTML, CSS og LiteSpeed webservere er Bjarnes foretrukne redskaber, og open source-fællesskabet hans komfortzone.

Bjarne bor i Sønderborg i et lille hus med en vild have og en doven kat.

Efterlad et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *