Login

10 Header-Einträge die eine Webseite sicherer machen

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.

.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!

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 Praeventions-/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 ueber 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) 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

10) Expect-CT

ssl-red-lockEiner der jüngsten Header, der noch in einem früheren Stadium als der für die Referrer Policy ist, ist “Expect-CT”. Dieser Header, den Chrome und Firefox auswerten wollen, 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.

Die Einstellungen erlauben die Protokollierung, ob es zu Fehlversuchen beim Aufruf der Webseite kam, insofern kann der Header schon jetzt verwendet werden.

# Expect-CT fuer kommende Implementation Okt 2017
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.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *
Bitte beachte, dass sich Dein Kommentar auf den Artikel beziehen sollte. Wenn Du ein persönliches Kundenanliegen besprechen möchtest, wende Dich bitte an unseren Kundenservice auf Facebook, Twitter oder über unsere Support-Seite.