Security Header

Security Header

Kevin Ditscheid 19. November 2018 Expert Topics

1 Kommentar // Lesezeit: 6 min.

Maßnahmen um die Client-Sicherheit zu erhöhen

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:

Header always set Content-Security-Policy "default-src 'self';"

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.

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://*.googleapis.com; font-src 'self' https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com; img-src 'self'; frame-src 'self' https://www.youtube.com https://www.youtube-nocookie.com"

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

script-src 'self' https://*.googleapis.com;

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/

Feature Policy Header

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:

Header always set Feature-Policy "geolocation 'none'; midi 'none'; camera 'none'; usb 'none'; magnetometer 'none'; accelerometer 'none'; vr 'none'; speaker 'none'; ambient-light-sensor 'none'; gyroscope 'none'; microphone 'none'"

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

X-Frame Options - Header

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:

Header always set X-Frame-Options "SAMEORIGIN"

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

Header always set X-Frame-Options "allow-from https://example.com/"

XSS protection - Header

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.

Header always set X-Xss-Protection "1; mode=block"

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

Header always set X-Xss-Protection "1; report=www.example.com/incident-reports"

Referrer policy - Header

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.

Header always set Referrer-Policy "strict-origin"

X-Content Type Options - Header

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.

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

Script Integrity

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

Wie man die Security Header testen kann

Es gibt ein Tool, mit dem man die Security Header testen kann: https://securityheaders.com

Ihr könnt die Adresse der Seite, welche getestet werden soll, in das Eingabefeld eintragen und auf den Scan-Button drücken.

Im darauf folgenden Report werden euch Informationen über die Antwort des Servers aufgezeigt. Hier werden die Security Header aufgelistet und eure Seite erhält eine Bewertung nach dem Notensystem von A+ für sehr gut bis F für sehr schlecht.

Wenn dort steht, dass die Bewertung auf die Note A beschränkt ist, bedeutet das, dass die gesetzten Security Header noch verbesserungswürdig sind. Was genau bemängelt wird, steht in den Warnungen weiter unten in den Informationen und könnte auf die Nutzung von 'unsafe-inline' Anweisungen hindeuten.

Das Tool gibt euch ebenfalls weiterführende Informationen zu den Security Headern, als auch zu vielleicht in Zukunft relevanten Headern.

Unsere eigene Software

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.


1 Kommentar

  • Peter

    Peter

    vor 3 Wochen

    Danke für den ausführlichen Artikel! Eine Frage zur CSP: werden die Prefixe "X-Content-Security-Policy" und "X-WebKit-CSP" aktuell nicht mehr gebraucht weil auch Firefox und Safari mittlerweile [...] Danke für den ausführlichen Artikel! Eine Frage zur CSP: werden die Prefixe "X-Content-Security-Policy" und "X-WebKit-CSP" aktuell nicht mehr gebraucht weil auch Firefox und Safari mittlerweile "Content-Security-Policy" verstehen?

    Dateien hier ablegen
Dateien hier ablegen