HTTP Strict Transport Security
HSTS richtig auf Web-Servern implementieren
Rund 95 Prozent aller HTTPS-Server sind anfällig für "Connection Hijacking". Dieser Umstand eröffnet Cyberkriminellen die Chance, Man-in-the-Middle-Attacken und andere gravierende Cyberangriffe auszuführen - wie beispielsweise eine aktuelle Untersuchung von Netcraft zeigt. Der Grund für diese besorgniserregende Situation: Nur fünf Prozent aller HTTPS-Server haben "HTTP Strict Transport Security" (HSTS) richtig implementiert.
HTTP Strict Transport Security (RFC 6797, tools.ietf.org/html/rfc6797) ist ein Mechanismus, der dafür sorgen soll, dass Web-Anwendungen ausschließlich TLS (Transport Layer Security) nutzen, um eine sichere Übertragung von Daten zu gewährleisten. Er schützt Nutzer vor passiven Lauschangriffen und aktiven Man-in-the-Middle-Attacken (MITM). Zudem setzt HSTS strikte Sicherheitsmaßnahmen durch, indem es beispielsweise das Laden von gemischten Inhalten sowie ein "Durchklicken" bei Sicherheitswarnungen für Zertifikate verhindert. Gleichzeitig schützt dieser Mechanismus vor Web-Server-Fehlern wie dem Laden von Javascript über eine unsichere Verbindung. HSTS dient somit als sicherer Schirm gegen alle Angriffe auf diesen Wegen.
HSTS implementieren
Web-Anwendungen sollten von der Annahme ausgehen, dass Cyberkriminelle bei jeder Domain/Subdomain einen MITM-Angriff über eine Klartext-HTTP-Verbindung ausführen können - beispielsweise mithilfe gespoofter DNS-Einträge. Gültiger HTTPS-Verkehr über die Domains/Subdomains lässt sich jedoch nicht abfangen, weshalb der Schutz mit einer geeigneten HSTS-Policy empfehlenswert ist. HSTS-Header lassen sich auf semantisch unterschiedlichen Wegen senden, die in dem dafür relevanten RFC 6797 wie folgt definiert sind:
Strict-Transport-Security: max-age=31536000. Die HSTS-Policy findet nur auf die Domain des HSTS-Hosts Anwendung, der sie ausstellt, und bleibt ein Jahr in Kraft.
Strict-Transport-Security: max-age=31536000; includeSubDomains. Die HSTS-Policy kommt sowohl auf der Domain des ausstellenden Hosts als auch auf dessen Subdomains zur Anwendung und bleibt ein Jahr in Kraft.
Strict-Transport-Security: max-age=0. Dies weist den Browser an, die gesamte HSTS-Policy zu löschen.
Best Practices für HSTS
Es gibt eine Reihe einfacher Best Practices für HSTS:
1. Am stärksten ist die Schutzwirkung, wenn sichergestellt ist, dass alle angeforderten Ressourcen ausschließlich TLS mit einem HSTS-Header verwenden.
2. Es ist ratsam, den Wert der "max-age"-Direktive auf größer als 10.368.000 Sekunden (120 Tage) und idealerweise auf 31.536.000 Sekunden (ein Jahr) zu setzen. Websites sollten den "max-age"-Wert nach Möglichkeit erhöhen, um mehr Sicherheit für die aktuelle Domain und/oder Subdomains über einen langen Zeitraum zu gewährleisten.
3. Laut RFC 6797, Absatz 14.4, sollten Web-Anwendungen der Policy die Direktive "includeSubDomain" hinzufügen, wann immer dies möglich ist. Diese Direktive gewährleistet, dass die HSTS-Policy auf die Domain des ausstellenden Hosts sowie alle seine Subdomains zur Anwendung kommt: beispielsweise "example.com" und "www.example.com".
4. Die Anwendung sollte niemals einen HSTS-Header über einen HTTP-Header im Klartext senden, weil die Verbindung dadurch anfällig für SSL-Stripping-Angriffe (SSL: Secure Sockets Layer) wird.
5. Es ist nicht empfehlenswert, eine HSTS-Policy über das Attribut "http-equiv" eines Meta-Tags zu implementieren. Laut RFC 6797 dürfen Benutzeragenten das Attribut http-equiv=“Strict-Transport-Security“ in -Elementen der empfangenen Inhalte nicht beachten ("must not").
Die Preload-Liste
HSTS ist vom klassischen "Henne-Ei-Problem" betroffen: Hat ein Browser eine bestimmte HSTS-taugliche Website noch nie zuvor besucht, weiß er nicht, dass die Website HSTS-tauglich ist und wird somit versuchen, eine HTTP-Verbindung aufzubauen, die anfällig für einen SSL-Stripping-Angriff ist. Browser, die HSTS unterstützen, versuchen, dieses Problem mithilfe einer "Preload"-Liste in den Griff zu bekommen. Dabei handelt es sich um nichts anderes als eine Liste bekannter HSTS-Hosts. Unter www.chromium.org/hsts ist zum Beispiel die gesamte Preload-Liste für Chrome zu finden. Die Domains in der Preload-Liste des Browsers werden "out of the box" mit HSTS konfiguriert. Um Web-Anwendung in die HSTS-Preload-Liste aufzunehmen, ist es ausreichend, eine Anfrage an hstspreload.appspot.com zu schicken.
Verwendung der Direktive "includeSubDomains"
Die Direktive "includeSubDomains" auf die Top-Level-Domain anzuwenden, ist nicht immer praktikabel - beispielsweise dann nicht, wenn es eine Subdomain gibt, die via HSTS nicht funktioniert. In diesem Zusammenhang sind folgende Faktoren zu berücksichtigen:
Es ist teuer, jeden Subdomain-Server mit einem gültigen, CA-signierten Zertifikat auszustatten. Ist HSTS aktiviert, hindert der Browser die Nutzer daran, selbstsignierte Zertifikate für Subdomains zu verwenden.
Unsichere Ressourcen werden Seiten nicht laden, die problemlos über TLS funktioniert hätten, wenn keine HSTS-Policy implementiert gewesen wäre.
Die Anwendung der Subdomains-Direktive ist also nur dann empfehlenswert, wenn sämtliche Sites für den betreffenden Domain-Namen TLS/SSL erfordern. Bevor man die Direktive "includeSubDomains" hinzufügt, sind die Auswirkungen auf vorhandene Drittanbieter-Dienste wie E-Mail oder DNS-CNAME-Einträge für CDNs (Content Delivery Networks) zu prüfen.
Da HSTS vor einem breiten Spektrum von Angriffen schützt, von Browsern weithin unterstützt wird und sich mit einer einzeiligen Einstellung konfigurieren lässt, sollten alle vom Internet aus erreichbaren Web-Anwendungen diesen Sicherheitsmechanismus nutzen. Unabhängig davon, welche Tools Unternehmen einsetzen, sollten sie bereits in einem frühen Stadium des Entwicklungs-Lebenszyklus sichere Programmiertechniken anwenden, auf HSTS-Tauglichkeit achten sowie dafür sorgen, dass Entwickler die Sicherheit vom ersten Tag an im Blick haben.
Lesen Sie mehr zum Thema
