10 Header-Einträge die eine Webseite sicherer machen

Hinweis: Dieser Artikel wurde zuletzt aktualisiert am 08.06.2020
Aktuelle Software inkl. Browser, der Einsatz einer Antivirussoftware, Verbindungen nur über SSL und gesunder Menschenverstand schützen vor Befall mit Viren und Malware aus dem Internet. Doch was kann man tun, um als Betreiber einer Webseite diese vor Hacker-Attacken und auch die Besucher zu schützen?

SSL/TLS gilt als sicherer Weg zur Datenübertragung zwischen Client und Server. Dazu gehört aber viel mehr, wie beispielsweise die im Hintergrund auf dem Webserver installierte aktuelle Chiffren-Sammlung.

Kaum Einflussnahme als Anwender

Die Einflussnahme als Anwender ist beim Thema SSL-Ciphern meistens stark eingegrenzt, außer man hat Root-Rechte auf dem Server und weiß, was man tut. Dies ist jedoch spätestens im Shared-Hosting bei keinem Anbieter der Fall. Dennoch kann man selbst auch einige zusätzliche Einstellungen vornehmen, die sich direkt oder indirekt auf das Verhalten von Skripten auf der Webseite und der damit einhergehenden Sicherheit auswirken. Dazu können die Header, die der Webservers wie z.B. Apache oder Nginx zurückgeben, optimiert werden.

.htaccess als Abhilfe

Im Regelfall hat man Zugriff mittels FTP/SSH oder Web-Oberfläche, um Dateien auf seinem Webspace anzulegen und zu editieren. Eine solche Datei ist die .htaccess die für viele als Ort der Weiterleitungen für die Webseiten, Passwortschutz oder Angabe von Caching-Einstellungen geläufig ist. (Stichwort “mod rewrite”).

Diese Konfigurationsdatei kann allerdings noch viel mehr und teilt dem Apache-Webserver die Optionsparameter mit, mit denen er laufen soll. Dafür ist zwar auch die “httpd.conf” zuständig, allerdings liegt diese im Regelfall außerhalb des für den einzelnen Benutzer zugreifbaren Bereichs.

10 Punkte .htaccess Sicherheits-Tuning

Kommen wir nun zur eigentlichen Konfiguration der .htaccess-Datei über die eine ganze Reihe an Header-Einträge (HTTP-Header-Felder) konfiguriert werden können.

1) HTTP Strict Transport Security (HSTS)

Der Webserver teilt dem Browser mit, dass alle künftigen Anfragen per SSL gesendet werden müssen.

# HSTS verwenden
# Pflichtangabe: max-age""
# Optional: "includeSubDomains"
Header set Strict-Transport-Security "max-age=31556926; includeSubDomains"

Bedeutung: Verbiete alle unsicheren Verbindungen für die nächsten 365 Tage zu meiner Domain, inklusive Subdomains.
Achtung: Der gewählte Zeitraum ist sehr lang und hat man eine Subdomain ohne SSL-Zertifikat können Benutzer diese nicht mehr aufrufen!
Ist diese Option eine Weile aktiv und funktioniert alles wie gewünscht, empfiehlt es sich, noch ein “; preload” am Ende hinzuzufügen. Details zur Prüfung, ob das SSL-Zertifikat und die gewählten Einstellungen funktionieren sowie weitere Informationen zur Preoload-Option finden sich auf: https://hstspreload.org .

2) X-Content-Type-Options

Ursprünglich mit dem IE8 eingeführt unterstützen mittlerweile neben Chrome auch Firefox und Safari diesen Typ. Die Einstellung unterbindet, dass unabhängig vom deklarierten Content-Type (z.B. text/html) nach weiteren möglichen MIME-Types gesucht/ausprobiert wird. Es wird quasi der Zugriff blockiert wenn der angefragte Typ “style” und der MIME-Typ nicht “text/css” ist oder wenn “script” verwendet wird und der MIME-Typ nicht einer der JavaScript MIME types ist.

# Verhindert mime based attacks, nur IE und Chrome
Header set X-Content-Type-Options "nosniff"

3) X-XSS-Protection

Fast alle aktuellen Browser liefern einen eingebauten Cross-Site-Scripting (XSS)-Filter mit, der eine Warnung zeigt, sollte mittels XSS versucht werden, dem Nutzer eine andere Datei unterzuschieben. Ein Benutzer kann diesen aber abschalten, ob bewusst oder unbewusst z.B. durch eine Browsererweiterung. Zudem wird er nur im IE, Chrome und Safari unterstützt. Der Header aktiviert diesen Schutz aber für eure Seite.

# Aktiviert XSS Präventions-/Filter-Tools
# Optional: mode=block
Header set X-XSS-Protection "1; mode=block"

Bedeutung: Aktiviere die Filterung aber versuche nicht selbst die Seite ohne den möglichen schadhaften Inhalt darzustellen, sondern blockiere Sie.

4) X-Frame-Options

Legt fest, ob dem Browser erlaubt wird, eine Seite in einem frame oder iframe darzustellen. Verschiedene Werte sind möglich.

DENY: Kein Rendering der Seite, sofern Sie in einem iframe / frame geladen wird
SAMEORIGIN: Rendering der Seite erfolgt, wenn der frame / iframe von eurer Domain ist
ALLOW-FROM DOMAIN: Erlaubt die Angabe einer Domain, die ein frame / iframe darstellen darf

# Begrenzung der frame/iframe Darstellung
Header append X-Frame-Options "SAMEORIGIN"

5) HTTP Public Key Pinning (HPKP)

Einer der für Laien schwierigste zu konfigurierende Header. Besitzt man ein SSL-Zertifikat kann man dem anfragenden Browser mitteilen, wie lange dieses noch gilt und einen “Schlüssel” = eine eindeutige Kennung senden. Damit kann beim erneuten Aufruf festgestellt werden, ob das Zertifikat noch das ist, was es sein sollte.

Verliert man als Anbieter aber diesen privaten Schlüssel, werden unabsichtlich alle Besucher ausgesperrt; zumindest für den definierten Zeitrahmen. Deshalb existiert noch ein Ersatz-Schlüssel, der, wenn das Zertifikat ausgetauscht wird, dann ebenfalls verwendet wird und zum ersten Schlüssel werden muss.

Auf den genauen Aufbau gehen wir an dieser Stelle nicht ein. Es finden sich zu diesem Thema jedoch genug Anleitungen im Netz z.B. im Mozilla Developer Network: Public Key Pinning

6) Set-Cookie

Mit diesem Header kann einiges zu Cookies gesteuert werden. Etwa wie lange dieser gültig ist, zu welcher Domain dieser gehört, welches Verzeichnis vorhanden sein muss, damit er gesetzt werden kann etc. Einer der wichtigeren Punkte ist aber, dass man bei Seiten die nur über SSL zu erreichen sind, ebenfalls nur Cookies per SSL beim Client/User erstellen lässt.

# Cookies nur über SSL and kein Javascript Zugriff
# Optional: Expires, Max-Age, Path, Domain
Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"

Bedeutung: Webseiten dürfen keinen Cookie setzen, wenn sie nicht per https aufgerufen werden. Erstellte Cookie sind zudem nicht über JavaScript auslesbar (mittels Document.cookie), schützt vor möglichen XSS.

7) X-Powered-By

Der X-Powered-By Header gibt im Regelfall die verwendete PHP-Version aus und kann es zusammen mit dem Server-Header einem Angreifer leichter machen, euer System zu attackieren. Denn kennt er die genaue Version des Webservers und der eingesetzten PHP-Version kann er gezielt bekannte Schwachstellen von diesen einsetzen, um in die Webseite einzubrechen.

# Kein PHP und System-Version ausgeben
Header unset X-Powered-By

8) Content-Security-Policy (CSP)

Auch Content-Security-Policy ist ein Sicherheitskonzept, das primär das Einschleusen von Dateien unterbinden soll aber noch einiges mehr kann. Es stellt quasi die Whitelist dar, von welchen Domains Javascripte, Bilder, Schriftarten und andere Inhalte auf eurer Seite eingebunden werden. Diese Ausnahmeliste kann sehr lang werden, wenn beispielsweise Social-Media-Kanäle auf der Webseite eingebunden werden oder jquery über ein CDN geladen wird, Ihr Schriftarten von Googlefonts verwendet oder verschiedene Zahlungsanbieter wie Paypal integriert wurden.

# Download / Lade Inhalte nur von Seiten die explizit erlaubt sind
# Beispiel das alles von der eigenen Domain erlaubt allerdings keinerlei Externas:
Header set Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';"

Wichtig dabei zu wissen ist, dass die Liste regelmäßig kontrolliert werden sollte. Wenn z.B. ein neues Plugin eingesetzt wird, prüfen, ob dieses auch seine benötigten Inhalte laden kann. Man sieht dies in der Entwickler-Konsole in jedem Browser anhand einer Fehlermeldung wie z.B. “Refused to load script from ‘webseite.endung’ because of Content-Security-Policy.” Alternativ kann man das auch in eine Datei speichern lassen (report-uri).

Wer übrigens eine saubere CSP-Liste besitzt, kann sich theoretisch die Einstellung für “X-XSS-Protection” (Punkt 3) sparen, denn es gibt damit eine klare Erlaubnisliste (Whitelist) welche Domains bei euch überhaupt auf der Seite interagieren können.

9) Feature-Policy
Ähnlich der vorangegangenen CSP ist diese Policy zu sehen und zu verwenden. Dieser Header bietet einen Mechanismus, mit dem die Verwendung von Browserfunktionen in einem eigenen Frame und im Inhalt von iframe-Elementen im Dokument zugelassen und verweigert werden kann. Beispielsweise kann damit eure Webseite einem Smartphone mitteilen, dass kein Inhalt Zugriff auf das Gyroskop oder die Kamera anfordern wird.

# Kein Zugriff auf Telemetriedaten von Browserfunktionen
# Beispiel, dass kein Zugriff auf Daten von das Sensoren, Kamera, Mikrofon oder USB-Slot erfolgt:
Header set Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'self'; microphone 'none'; midi 'none'; usb 'none';"

Dieser Header ist noch relativ neu und die Implementierung und Detail-Unterstützung einzelner Werte je Browser ist unterschiedlich. Mozilla sieht die Feature-Policy mit Stand Juni 2020 noch als experimentell an.

10) Referrer Policy

Dieser Header regelt, welche Referrer-Informationen, die im Referrer-Header gesendet wurden, in Anfragen aufgenommen werden sollen. Es gibt relativ viele verschiedene Optionen, die man hierbei setzen kann. Neben Firefox unterstützen zwar auch Chrome und Opera diesen Typ bereits, allerdings noch nicht alle der möglichen Optionen.

Der Grund dafür ist relativ einfach: Es handelt sich bei diesem Header um den aktuellen Empfehlungskandidaten des W3C vom 26 Januar 2017. Wer diesen Header also jetzt schon einsetzt, darf sich rühmen, seiner Zeit voraus zu sein 😉

# Referrer Policy
Header set Referrer-Policy "origin-when-cross-origin"

Bedeutung: Sende die vollständige Referrer-URL, wenn du auf der selben Domain bleibst. Sobald https verlassen oder eine anderer Domain angesprochen wird, sende nur die Quell-Domain.

Details zu diesem Header finden sich im offiziellen Dokument des W3C:
Referrer Policy – W3C Candidate Recommendation, 26 January 2017

11) Expect-CT (bis 2021)

Einer der jüngsten Header, der 2017 in einem früheren Stadium als der für die Referrer Policy war, ist “Expect-CT”. Dieser Header, den Chrome und Firefox auswerten, soll zeigen, ob es Fehler in der Implementation von SSL-Zertifikaten gibt. Ist der Header aktiv, wird beim Aufbau einer SSL-Verbindung im Browser diese Option gespeichert und bei einem wiederkehrenden Besuch die Verbindung abgelehnt, sofern die Einstellungen der Webseite nicht mit den festgelegten Zertifikats-Transparenz-Regeln übereinstimmen.
Expect-CT wird voraussichtlich im Juni 2021 allerdings obsolet werden, da es seit Mitte 2018 erforderlich ist, dass neue ausgestellte Zertifikate standardmäßig sog. STCs unterstützen, die Expect-CT prüft. Ältere Zertifikate, die vor März 2018 ausgestellt wurden, können eine maximale Gültigkeitsdauer von 39 Monaten haben, wodurch diese alle im Juni 2021 ablaufen.

Die Einstellungen erlauben die Protokollierung, ob es zu Fehlversuchen beim Aufruf der Webseite kam:

# Expect-CT
Header set Expect-CT "max-age=0; report-uri=https://domainname.endung/reportOnly"

Bedeutung: Dieser Eintrag erstellt derzeit nur in der Datei “reportOnly” Einträge, sofern es zu Fehlern kommt.

Header jetzt setzen und online prüfen

Die genannten Header werden mittlerweile auch bei vielen Online-Checks in Bezug auf sichere Webseiten geprüft und nehmen Einfluss auf deren Benotung.

• https://www.immuniweb.com/websec/ – alle oben genannten Optionen werden geprüft inkl. Referrer Policy
• https://securityheaders.io – verwendet ebenfalls alle vorgestellten Header für die Berechnung der Note inkl. Referrer Policy und zeigt zusätzlich auch an, ob der Expect-CT-Header schon implementiert wurde
• https://www.ssllabs.com/ssltest – HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP) werden geprüft