Een HTTP-reactieheader is wat de webserver terugstuurt naar de browser, vóórdat de content wordt getoond. Een header zie je dus niet altijd, het bevindt zich op de achtergrond. Dat wat de browser -of client- stuurt naar de webserver, heet een verzoekheader (vandaar: Request header en Response header).

In reactieheaders staat veel informatie, soms te veel informatie. Ook kun je er veel zaken in regelen, zoals hoe een browser zich gedragen moet, of wat de server moet terugsturen. Hiermee kun je de beveiliging van jouw website beter en strikter maken.

Dit artikel geeft jou uitleg.

In een ander artikel hebben we je utigelegd dat je met een HTTP Strict-Transport-Security reactieheader volledige SSL-versleuteling tussen client en server kunt forceren.

Zo is er nog een aantal headers dat aandacht behoeft:

  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection
  • Server
  • Content-Security-Policy

Ja, dit is een ingewikkelder en geavanceerder artikel, maar wij vinden het wél belangrijk dit te benoemen. In het kort uiteraard.

Je vindt op de website van het Open Web Application Security Project (OWASP , en speciaal voor WordPress: OWASP WordPress Security Implementation Guideline) belangrijke en handige informatie over deze HTTP-headers. Op internet.nl en securityheaders.io vind je meer handige informatie.

Ook van belang is het goed instellen en terugsturen van beveiligde cookies.

Na de tekstuele uitleg hieronder plaatsen we alle genoemde headers in een voorbeeld web.config-bestand.

X-Content-Type-Options

Als je de HTTP-header X-Content-Type-Options de waarde “nosniff” meegeeft dan houdt dat in dat een browser zoals Internet Explorer, en in sommige gevallen Google Chrome, niet zelf probeert te achterhalen welk type bestand wordt gestuurd.

De browser moet uitgaan van het Content-Type dat de website/server terugstuurt.

X-Frame-Options

Met X-Frame-Options kun je instellen vanaf welk domein een frame of iframe geladen mag worden. De waarde kan “deny” zijn om het laden van externe frames tegen te gaan, “sameorigin” om alleen frames vanaf hetzelfde domein – of dus jouw website – te tonen, en “allow-from: DOMAIN“, om van een specifiek domein frames te laden. Hierbij moet je DOMAIN dus vervangen door de desbetreffende domeinnaam.

Let op: WordPress zet zelf een X-Frame-Options header. Doe je dit ook met behulp van het web.config-bestand dan conflicteert dat en kun je ongewenst gedrag van jouw WordPress website verwachten. Hierom is de header uitgecommentarieerd in het voorbeeld hieronder, maar wel geplaatst ter illustratie. Je kunt deze header wél zelf plaatsen als je geen WordPress gebruikt en jouw website dit niet zelf doet.

X-XSS-Protection

De X-XSS-Protection header schakelt het Cross Site Scripting filter van browser in. Hiermee wordt het moeilijker gemaakt om via de browser Cross Site Scripting (of XSS) aanvallen uit te voeren op websites.

Deze XSS-beveiliging staat vaak standaard ingeschakeld in browsers, maar mocht een kwaadaardige gebruiker dit hebben gedeactiveerd, dan kun je het hiermee forceren. Geef het de waarde “1; mode=block” mee.

Server

Server reactieheader: Een webserver mag graag vertellen welke software hij draait, bijvoorbeeld Windows Server IIS 8.5 of Apache 2.4. Voor aanvallers kan dit heel waardevolle informatie zijn en daarom heeft het de aanbeveling om deze Server: HTTP-reactieheader te legen. Verwijderen kun je de header helaas niet, wel kun je het besturingssysteem of webserver-versie eruit verwijderen, of er zelf iets voor in de plek zetten.

Content-Security-Policy

Content-Security-Policy, of CSP, is een heel ingewikkelde header. Hierin moet je precies aangeven welke content wel geladen mag worden op jouw website, en al het andere mag simpelweg niet. Ga je hiermee aan de gang, maak dan veelvuldig gebruik van de Chrome of Firefox hulpprogramma’s console. Deze console is bereikbaar via de sneltoets F12.

Omdat elke website weer anders is kunnen wij helaas geen goed voorbeeld hiervan geven, behalve een klein stukje ter illustratie (LET OP: niet overnemen in jouw website!). Zie http://w3c.github.io/webappsec-csp/ voor alle relevante technische informatie, een beter begrijpbare introductie staat op http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

Voorbeelden

Hieronder volgen de web.config-voorbeelden die je over kunt nemen in het web.config-bestand van jouw website. Let er te allen tijde op dat je geldige XML-syntaxis gebruikt, het kan zijn dat je zelf de juiste locaties moet vinden of maken in het web.config-bestand om delen van het onderstaande toe te voegen.

HTTP reactieheaders regelen in jouw web.config-bestand

X-Content-Type-Options, X-Frame-Options, X-XSS-Protection: het eerste deel van het voorbeeld is eenvoudig. In de XML node httpProtocol > customHeaders (let op de casing van hoofdletters en kleine letters) kunnen we headers verwijderen en toevoegen. Je doet dit met behulp van de headernaam en de opdracht remove of add.

Het voorbeeld zie je hieronder:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
    <!-- X-Frame-Options is sometimes set by WordPress, this one might conflict -->
    <add name="X-Frame-Options" value="deny" /> <!-- of 'SAMEORIGIN' -->
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="Content-Security-Policy" value="default-src 'self'; script-src https://cdn.example.com/scripts/; object-src 'none'; plugin-types application/pdf application/x-shockwave-flash;" />
  </customHeaders>
</httpProtocol>

.htaccess:

Header set X-Content-Type-Options nosniff
Header set X-Frame-Options SAMEORIGIN  # of 'deny'
Header set X-XSS-Protection "1; mode=block"
Header set Content-Security-Policy "default-src 'self'; script-src https://cdn.example.com/scripts/; object-src 'none'; plugin-types application/pdf application/x-shockwave-flash;"

Server: header verwijderen

Helaas valt de Server: reactieheader niet in de categorie customHeaders van httpProtocol in het web.config-bestand. Zoals al geschreven kun je deze header niet verwijderen, maar wel legen. En dat moet met een URL Rewrite outboundRule (een IIS URL Rewrite regel om in de output stream of uitvoerstroom van de webserver wijzigingen aan te brengen).

De output stream is de reactie die de server terugstuurt naar de browser, ofwel de reactieheaders + pagina HTML-broncode.

Neem in het web.config-bestand het volgende op:

  <outboundRules rewriteBeforeCache="true">
    <rule name="Remove Server header">
      <match serverVariable="RESPONSE_Server" pattern=".+" />
      <action type="Rewrite" value="" />
    </rule>
  </outboundRules>

en wel ná de afsluiting van de WordPress Permalink rewrites:


    </rule>
  </rules>

maar vóór de afsluitende </rewrite>.

Deze outboundRule zoekt in de uitvoerstroom naar de HTTP-reactieheader “Server:” en herschrijft of vervangt de waarde -bijvoorbeeld- “Microsoft-IIS/8.5” met niets (value=""). Als je wilt, kun je hierin jouw eigen informatie juist toevoegen, gewoon voor de fun, bijvoorbeeld:

<action type="Rewrite" value="Vevida speedy web server 1.0" />

In een .htaccess is dit helaas niet mogelijk.

Wat vond je van dit antwoord?

Bedankt voor je feedback!

Er is een fout opgetreden. Probeer het later opnieuw.