Security Header

Die folgenden Maßnahmen sind dazu gedacht, Besucher eurer Webseite vor Angriffen durch veränderte Ressourcen zu schützen, welche auf euren Webseiten eingebettet sind. Die Header können in der Web-Server Konfiguration, wie zum Beispiel einer htaccess bei apache, gesetzt werden und müssen an die spezifischen Anforderungen der Webseite angepasst werden.
Diese Anpassungen beschränken sich glücklicherweise meist auf spezielle, externe Ressourcen und Feature.

Content Security Policy - Header

Der CSP Header kann dazu genutzt werden, um dem Browser zu zeigen, welche Ressourcen und Skripte gefahrlos von welchen Quellen geladen werden dürfen.
Das bedeutet, dass alle externen Ressourcen, welche nicht im CSP Header gelistet sind, nicht vertrauenswürdig sind und damit vom Browser auch nicht geladen und ausgeführt werden. Dies kann Attacken wie zum Beispiel Cross-Site-Scripting, manipulierte Bilder oder versteckte iFrames verhindern oder zumindest erheblich erschweren.

Zum Beispiel:

Diese Anweisung lässt den Browser sämtliche Ressourcen und Skripte ignorieren, welche über script-. link-, img-, iframe- oder object-Tags eingebettet werden und nicht von der gleichen Domain stammen, auf welcher der Benutzer sich grade befindet.

Weil eine Menge Webseiten jedoch Gebrauch von externen Diensten machen, von CDNs  bis Stock-Images, ist dieses Beispiel kein brauchbarer Weg, eine Webseite sicher zu gestalten. Zum Glück lässt sich der Header anpassen, um bestimmte externe Ressourcen zu erlauben und für den Browser als "sicher" zu kennzeichnen.

Dieser Header macht schon mehr Sinn, da er den Zugriff auf bestimmte Ressourcen und Dienste erlaubt.

Diese script-Direktive zum Beispiel erlaubt das Einbinden von Skripten sowohl von der aktuellen Domain über 'self', als auch von Skripten von jeder Subdomain von googleapis.com über HTTPS.

https://developers.google.com/web/fundamentals/security/csp/

Der Feature Policy - Header kann Skripten den Zugriff auf Geräte und Fähigkeiten des Browsers erlauben und verbieten. In den meisten Fällen muss man externen Skripten zum Beispiel keinen Zugriff auf die Kamera oder das Mikrofon des Besuchers gewähren. Somit kann man den Zugriff auf diese Geräte sperren, damit im Falle eines erfolgreichen Einschleusens von Code auf der Webseite, der Angreifer keine Möglichkeit besitzt, die Sensoren des Gerätes zu übernehmen, mit dem der Besucher die Seite besucht, und ihn somit auszuspähen.

Um Zugriff auf alle Geräte wie Kamera oder Lautsprecher zu verbieten, können wir Folgendes schreiben:

Damit ist der Zugriff auf diese Geräte für sämtliche Skripte untersagt.

Falls ein Skript jedoch legitimerweise Zugriff auf einen Sensor oder Gerät benötigt, können wir dies dem Browser mitteilen, indem wir den Zugriff für Skripte auf unserer eigenen Domain mittels 'self' freigeben, oder den Domainnamen eintragen, von welchem das Skript stammt. In etwa so:  geolocation maps.google.com.

https://developers.google.com/web/updates/2018/06/feature-policy

Der X-Frame Options Header wird dazu genutzt dem Browser zu sagen, ob die Webseite in einem iFrame angezeigt werden darf oder nicht. Dies zielt auf mögliche Phishing Attacken ab, bei denen die Webseite in ein Iframe auf einer fremden Seite eingebettet wird, um dem Nutzer vorzugaukeln, er würde sich auf der Original-Webseite bewegen, während in Wirklichkeit seine Daten von dieser Fake-Webseite abgegriffen werden können.

Um eine Einbettung der Webseite nur auf ihrer eigenen Domain zu erlauben, zum Beispiel für den Einsatz in einer Lightbox:

Ihr könnt auch einer bestimmten Domain erlauben, die Webseite als iFrame einzubetten, wenn ihr es explizit im Header erwähnt:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

Der XSS-Protection Header aktiviert den Browserinternen XSS Filter. Browser wie Google Chrome oder der Internet Explorer besitzen eine Vorrichtung, um XSS Angriffe zu erkennen und zu verhindern.

In Zukunft werden die Browser wohl auch in der Lage sein, einen XSS-Angriffsversuch an eine bestimmte URL zu melden.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

Der Referrer Policy - Header gibt an, unter welchen Umständen die aktuell besuchte URL an die nachfolgend besuchte Seite übertragen wird. Er kann so konfiguriert werden, dass die URL nur an die eigene Domain und in Teilen an externe URLs weiter gegeben wird. Dies dient dazu, den Besucher vor dem Ausspionieren durch nachfolgend besuchte Webseiten zu bewahren.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Der X-Content-Type-Options Header hat nur einen erlaubten Wert:  "no-sniff". Der Header wird dazu genutzt den Browser zu instruieren, auf den gesetzten Content-Type Header des Servers zu vertrauen und nicht eigenständig zu versuchen, den korrekten MIME-Type einer Datei heraus zu bekommen. Dies kann Angriffe durch einen versteckten MIME Type verhindern, bei welchen dem Browser vorgegaukelt wird, bei der Datei handele es sich zum Beispiel um eine ausführbare Datei. Der Browser wird die Datei bei einem Mismatch des Content-Type ignorieren.

developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Das integrity-Attribut von script- und link-Tags kann dazu dienen, Code-Einschleusungen, zum Beispiel durch gekaperte CDNs, zu erkennen und zu verhindern. Dazu kalkuliert der Server, welcher das Skript bereit stellt, einen Hash aus dem originalen Dateiinhalt, welcher in unserem eigenen Server als integrity-Attributwert hinterlegt wird. Lädt der Browser nun unsere Webseite, wird er, bevor er das entsprechende Skript ausführt, den von unserem Web-Server mit geschickten Hash mit dem gehashten Inhalt der Datei vergleichen, welche vom Browser ausgeführt werden soll. Sollte der Hash mit dem Dateiinhalt der auszuführenden Datei nicht übereinstimmen, wird der Browser die Ausführung der Datei verweigern.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

Wir bei sgalinski Internet Services haben uns die Mühe gemacht, unsere internen Tools so sicher wie möglich zu gestalten. Unsere website-base besitzt deswegen eine Basis-Implementierung der Security Header, welche eine A-Note bekommt, out-of-the-box.