Nachdem ich in den zwei vorhergehenden Artikeln über HSTS, X-XSS-Protection und die Content-Security-Policy geschrieben habe, folgen nun die letzten kleineren HTTP Security Header. Dazu zählen unter anderem X-Content-Type-Options, X-Frame-Options, Feature-Policy und Referrer-Policy. Auf der Webseite von OWASP, dem Open Web Application Security Project, findet ihr auch eine gute Übersicht aller Header, Einstellungsmöglichkeiten und Best Practices. Wie in den letzten Artikeln beschreibe ich die Umsetzung der Header mit Apache via .htaccess-Datei.

X-Content-Type-Options

Der Header ist recht simpel, denn er hat nur 1 mögliche Option: „nosniff“. Mit dieser Eigenschaft verhindert der Header, dass der Browser einen übermittelten Content-Type MIME type ändert. Stattdessen muss der MIME-Type in jedem Fall befolgt werden, was MIME sniffing Attacken (auch „content sniffing“ genannt) verhindern kann. Bei diesem Angriffsszenario werden Dateien mit einem falschen MIME-Type an den Browser geschickt, welcher diese dann anders als vorgesehen interpretiert:

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

X-Frame-Options

Die Angabe eines X-Frame-Options Header gibt vor, ob andere Seiten deine Seite einbinden können – als frame, iframe oder object. Verhindert werden dadurch vor allem Clickjacking Attacken. Damit steht dies im Gegensatz zur CSP, welche die Einbindung anderer Seiten in deine Seite behandelt. Drei Optionen stehen zur Auswahl: DENY, SAMEORIGIN und ALLOW-FROM [Domain].
Für WordPress ist es empfehlenswert, die Option SAMEORIGIN zu wählen, da es sonst Problemen geben wird, beispielsweise beim Update von Plugins.

Header always set X-Frame-Options "SAMEORIGIN"

Feature-Policy

Die Feature-Policy ermöglicht die Kontrolle vieler Browser-APIs und somit die Einschränkung der Angriffsquellen bei vielen Funktionen. Für jede Direktive (= API) können folgende Optionen gesetzt werden: * (alle Quellen erlaubt), self, none, [Domains]. Die Funktionalität ist also der CSP sehr ähnlich, aber mit Fokus auf Features. Auch wenn die Browserunterstützung noch recht mau ist, empfehle ich die Nutzung: Beschränkt die einzelnen APIs so, wie sie in eurer Seite benötigt werden und schafft damit etwas mehr Sicherheit. Eine report-Direktive ist wohl schon in Arbeit, aber noch nicht implementiert, ich hoffe das kommt bald noch.

Mehr Informationen zu den Direktiven auf dieser Google-Seite, der Github Seite (manche davon ausführlicher erklärt) und aktiv gezeigt auf dieser Demo-Seite. Das reicht als Hilfe für das Setup.

Ich aktiviere bei mir die Features autoplay, fullscreen und picture-in-picture für ’self‘, allesamt für embedded Videos brauchbar, der rest wird mit ’none‘ deaktiviert:

Header always set Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'self'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'self'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'self'; speaker 'none'; usb 'none'; vr 'none'"

Ihr findet diese und weitere Einstellungen auch in den Webseiten-Einstellungen, die für jede Webseite angepasst werden können. Eure lokalen Settings stehen dabei noch vor den von der Seite vorgegebenen Featureeinstellungen:

Referrer-Policy

Zuletzt noch die Referrer-Policy: Dieser Security Header steuert die Referrer-Information, die beim Aufruf eines Links auf eurer Seite mitgeschickt wird. Der Referrer ist dabei praktisch die Quelle der eingehenden Anfrage:

Grundsätzlich ist der Referrer eine nützliche Information, vor allem für Webseitenbetreiber und ihre Analysewerkzeuge wie Google Analytics. Sie erfahren, wie die Besucher auf die Webseite gekommen sind, von wo, eventuell mit welchen Suchbegriffen, und können ihre Seite mit diesen Informationen verbessern. Ich selber möchte hier also möglichst wenig restriktiv sein, aber dennoch die Sicherheit ein wenig erhöhen. Problematisch können Referrer-Informationen werden, wenn sie zu einer bösen oder unsicheren Seite weitergeleitet werden. Welche Möglichkeiten gibt es also?

Mögliche Optionen für die Referrer-Policy: no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url

Ich möchte jetzt hier nicht auf jeden Punkt eingehen, das wäre unnötig. Informiert euch gerne bei Mozilla (mitsamt Beispielen) oder in diesem Blog zu den Auswirkungen jeder Eigenschaft auf den Referrer.

Ich benutze aus oben genannten Gründen nur die Option ‚no-referrer-when-downgrade‚. Diese ist möglichst locker beim Aufruf beliebiger http://-Links und schickt den gesamten Referrer da mit. Ich habe in meinem Blog keine kritischen Informationen, die nicht weitergeschickt werden sollten. Allerdings wird die Weiterleitung meines Referrers auf unsichere http://-Seiten verhindert, das erhöht die Sicherheit ein wenig. Überdenkt eure Seite, eure Links und wie ihr mit dem Referrer selbst umgehen wollt.

Achtung WordPress-Nutzer: Ich glaube seit WordPress 4.7 werden target=“_blank“ Links automatisch mit der Eigenschaft rel=“noreferrer noopener“ erstellt. Das mag gute Hintergrundgedanken haben, wenngleich auch die Seite informiert, dass noopener den Angriff verhindert und noreferrer nur als compatibility backup benutzt wird.
Also unabhängig vom Referrer-Policy-Setting würden Links keinen Referrer mitsenden.
Es gibt mindestens 2 verschiedene Codes für die functions.php, mit der sich das deaktivieren lässt, beispielsweise siehe Link in diesem Absatz. Das Problem hierbei: Beide Codes funktionieren nicht mit dem neuen Gutenberg-Editor. Ich habe hier bisher keinen Weg gefunden, das automatische noreferrer zu entfernen und daher bleibt dieser Security Header bei mir mehr oder minder Placebo und für alle Fälle.

Fazit

Das waren nun also die wichtigsten sieben HTTP Security Header in drei Artikeln, das war doch eine ganze Menge neues Wissen. Ich hoffe, dass ihr etwas Hilfe finden und eure Webseitensicherheit ebenfalls verbessern konntet. Es gibt noch weitere Security Header, diese waren dann aber entweder kaum verbreitet, kaum unterstützt oder kritisch diskutiert und mir daher zu edge case für meine Artikel.

Im Großen und Ganzen bin ich zufrieden, auch wenn man sicher immer noch besser und sicherer sein kann, hier mein securityheaders.com Ergebnis: