Die sogenannten „HTTP Security Headers“ setzen sich aus einer Reihe zu treffender Schutzmaßnahmen zusammen und dienen z.B. dazu die Angriffsflächen für Cross-Site-Scripting (XSS), Code injections, MIME-type sniffing, Clickjacking („UI redress attack“), etc. zu minimieren. Hierfür werden spezifische HTTP-Antwort-Headerfelder eingesetzt, die dem Browser bei jedem Seitenaufruf Anweisungen geben, wie er mit bestimmten Daten umgehen soll bzw. wie er sich dabei zu verhalten hat.
Der Header dient als Schutz vor Cross-Site-Scripting (XSS) und ist unter Umständen der anspruchsvollste wenn es um die Konfiguration geht. Hierfür müssen nämlich alle potentiell geladenen Inhalte (z.B. Bilder, JavaScripts, etc.) über das Setzen auf eine so genannte „Whitelist“ erlaubt werden.
In diesem Header kann gesteuert bzw. eingeschränkt werden, wie viele Informationen eine extern aufgerufene Seite im so genannten „Referer header“mitbekommt. Der Referer verrät der nachfolgenden Seite von welcher Website/URL man kommt. Man kann also z.B. verhindern, dass eine unsichere Seite sensible Daten, wie eine URL mit gewissen Parametern in diesem Feld übergeben bekommt.
Mit der richtigen Einstellung dieses Headers kann man verbergen, welche Software auf dem Server verwendet wird bzw. welche Versionsnummer diese hat. Dies erhöht die Sicherheit, da ein potentieller Angreifer keinen Einblick auf diese Details hat.
Dieser Header dient dazu, das Verwenden von TLS/HTTPS zu erzwingen und verstärkt die Sicherheit um ein Vielfaches, da alle übertragenen Daten Clientseitig über eine sichere Transportebene transportiert werden.
Mit diesem Header kann man Steuern, ob die Website in einem Frame geladen werden darf oder nicht. Dadurch kann ein so genanntes „Clickjacking“, sprich eine perfide Methode um die Maus/Tastatureingaben zu missbrauchen, verhindert werden.
Der besagte Header wird verwendet um die eingebaute XSS-Schutzfunktion in den Browsern Internet Explorer, Chrome und Safari zu konfigurieren. Es handelt sich hier um eine Art „Fallback“ für ältere Browser, die den Content-Security-Policy noch nicht unterstützen. Für moderne Browser ist dieser Header weitesgehend uninteressant
Die Aktivierung dieses Headers verhindert „MIME sniffing“, sprich das verändern oder manipulieren eines fix angegebenen Inhaltstypen bei der Ausgabe in Browsern, wie dem Internet Explorer.
Der Einsatz von Security Headers sollte optimalerweise bereits vor einem Website-Launch geplant und in der Entwicklungsphase laufend getestet werden. Eine nachträgliche Implementierung ist, je nachdem wie Umfangreich ein Webshop oder eine Website ist bzw. wie strikt die Anforderungen/Einstellungen sein sollen, möglich und verschieden komplex umzusetzen.
Mit dem Scanner von securityheaders.io können Sie Ihre Seite überprüfen und erste Maßnahmen beschließen.
[rr]
