Blogbeitrag Security Header

Security Header: Ist Ihre Verbindung safe?

Dieser Artikel ist Nummer 7 von 8 im Special "Datenschutzgrundverordnung 2018"

Mehr Sicherheit für Ihre Webseite!

Security Header werden zusätzlich beim Verbindungsaufbau zwischen Browser und Server dazwischen geschaltet, also quasi „gesendet“. Header verhindern, dass eventuelle Sicherheitslücken missbraucht werden können.

Was sind Security-Header und wie sichern sie?

Immer wenn ein Browser eine Webseite von einem Server abruft, gibt der Server die Seite heraus und sendet einen HTTP-Response-Header mit dem Inhalt. Diese Header können Fehlercodes beinhalten. Jetzt kann man aber Anweisungen mit den Response-Headern mitsenden, die dem Browser genau sagen, was zu tun ist und wie er sich zu verhalten hat.

HTTP Strict-Transport-Security Line (HSTS)

Die HTTP Strict Transport Security Linie teilt dem Browser beim ersten Aufruf einer Domain oder auch der Subdomains mit, dass zukünftige Aufrufe nur über eine verschlüsselte Verbindung (https) erfolgen dürfen. Der Browser merkt sich diese Einstellungen für einen Zeitraum, der über den Parameter max-age festgelegt werden muss und verweigert den Zugriff über unverschlüsselte Verbindungen. Der Zeitraum wird in Sekunden definiert und man empfiehlt einen Wert von einem Jahr (31536000 Sekunden).

Strict-Transport-Security Header für HTTPS-Webseiten

Hier wird der Browser dann angewiesen, nur über eine sichere HTTPS-Verbindung auf die Webseite zuzugreifen. Eine unsichere und angreifbare Verbindung wird erst gar nicht hergestellt. Dieser HTTP-Response-Header verhindert auch den Zugriff von als nicht vertrauenswürdig eingestuften Browsern von Nutzern.

Der X-Frame-Options Header

Der X-Frame-Options Header legt fest, ob eine Webseite in einem Frame ausgeführt werden darf. Wenn man dem Browser verbietet, eine Seite auch per Frame zu laden, können Angriffe über sogenanntes Clickjacking verhindert werden. Das heißt, es werden gezielt Webseiten erstellt, die sich Inhalte von anderen Webseiten holen können. Diese Inhalte werden in einem Frame ausgeführt und sehen dann so aus, als ob die Inhalte von der eigenen Seite stammen. Aber dieser Header hat auch einen Nachteil: Die Webseite kann generell nicht mehr als Frame ausgeführt werden und sollte somit erst gesetzt werden, wenn sich die Webseite nicht mehr in der Entwicklung befindet.

X-Xss-Protection

Die neueren Browser haben den Schutz gegen Reflective XSS Angriffe schon eingebaut und können mit dem X-Xss-Protection Header ein- und ausgeschaltet werden. Angriffe werden mit einem zusätzlichen Parameter sogar blockiert statt nur gefiltert. Der Filter sollte bei allen Browsern grundsätzlich schon aktiviert sein. Dieser Header zwingt den Browser aber zum Aktiv sein und ist somit ein Must-have.
Man hat drei verschiedene Einstellmöglichkeiten:

  • 0 deaktiviert den Filter
  • 1 aktiviert den Filter, der Browser wird bereinigt und zeigt die schadhafte Seite an
  • 1; mode=block aktiviert den Filter und blockt die schadhafte Seite

X-Content-Type-Options Header

Dieser Header schützt vor Angriffen mit falschen MIME-Typen, denn wenn dieser als inkorrekt eingestuft wird, verweigert der Browser das Laden von Styles und Scripten. Ist der Header auf NONSNIFF gesetzt, werden nur die Styles und Scripte geladen, die einen korrekten MIME-Typ besitzen.

Referrer-Policy-Header

Dieser seit Anfang 2017 recht neue Header kann konfigurieren, ob und wie der Referrer bei Links, die auf der Webseite unterstützt werden, übergeben wird.

Content-Security-Policy-Header

Dieser Header muss von einem Profi umgesetzt werden, denn er kann eine Webseite bei unsachgemäßem Notieren direkt beeinflussen und auch lahmlegen. Sein Vorteil ist, dass
genau festgelegt werden kann, welche Inhalte woher vom Browser auf der Webseite geladen werden dürfen. Das Gefährliche ist, dass diese Angaben sehr individuell sind. Angaben individuell vom Inhalt der Webseite abhängen und muss unbedingt vor dem Go live getestet werden.

Warum wurde dieser Header also entwickelt? Es gibt sogenannte Code-Injection-Angriffe und dieser Header erstellt eine sogenannte Whitelist, in der alle Content-Quellen oder Arten, die erlaubt sind, aufgelistet sind. Alle anderen werden nicht vom Browser erst gar nicht geladen, auch wenn die Quelle nicht schädlich ist.

Public-Key-Pins-Header

Aus Gründen der Vollständigkeit erwähnen wir diesen Header noch am Schluss. Man kann diesen Header zwar ohne Bedenken setzen, er ist jedoch nur für Server-Profis einzurichten.

Security Header für mehr Sicherheit im Web

Wir haben Ihnen nun die wichtigsten HTTP Security-Header vorgestellt. Sie sind umzusetzen, indem die betreffenden Code-Snippets in die Server-Steuerungsdatei eingesetzt werden. Auch ein versierter Laie kann damit etwas für die grundlegende Sicherheit seiner Webseite tun. Eine hohe Sicherheit hingegen ist nur für IT-Fachleute zu erreichen. Die Schwierigkeit besteht in der Umsetzung, da der Adminbereich separat gesichert werden muss, wenn nicht alles freigegeben werden soll, was in einem Unternehmen so gut wie nie der Fall ist. Im letzten Schritt muss dann ein Test der Security Headers Konfiguration durchgeführt werden, wozu auch ein separates Tool erforderlich ist.

Weitere Beiträge dieser Serie« Cookie-Hinweis vs. Webdesign und Usability10 DSGVO-Fallen für Sie und Ihre Mitarbeiter »

Diesen Beitrag bewerten

0 Kommentare

Dein Kommentar

Möchtest du mitdiskutieren?
Fühl dich frei, beizutragen!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden .