Strict-Transport-Security header
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
Der HTTP Strict-Transport-Security
Antwort-Header (oftmals als HSTS abgekürzt) informiert Browser, dass der Host nur über HTTPS zugegriffen werden sollte und dass alle zukünftigen Zugriffsversuche über HTTP automatisch auf HTTPS aktualisiert werden sollen. Zusätzlich wird der Browser bei zukünftigen Verbindungen zum Host dem Benutzer nicht erlauben, sichere Verbindungsfehler, wie ein ungültiges Zertifikat, zu umgehen. HSTS identifiziert einen Host nur über seinen Domainnamen.
Header-Typ | Antwort-Header |
---|---|
Verbotener Anforderungs-Header | Nein |
Syntax
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload
Direktiven
max-age=<expire-time>
-
Die Zeit in Sekunden, die der Browser sich merken soll, dass ein Host nur über HTTPS zugegriffen werden darf.
includeSubDomains
Optional-
Falls diese Direktive angegeben ist, gilt die HSTS-Richtlinie auch für alle Subdomains der Domain des Hosts.
preload
Optional Nicht standardisiert-
Siehe Preloading Strict Transport Security für Details. Wenn
preload
verwendet wird, muss diemax-age
-Direktive mindestens31536000
(1 Jahr) betragen, und dieincludeSubDomains
-Direktive muss vorhanden sein.
Beschreibung
Der Strict-Transport-Security
Header informiert den Browser, dass alle Verbindungen zum Host über HTTPS erfolgen müssen. Obwohl es sich um einen Antwort-Header handelt, beeinflusst er nicht, wie der Browser die aktuelle Antwort behandelt, sondern wie er zukünftige Anfragen stellt.
Wenn eine HTTPS-Antwort den Strict-Transport-Security
Header enthält, fügt der Browser den Domainnamen des Hosts seiner persistenten Liste von HSTS-Hosts hinzu. Falls der Domainname bereits in der Liste ist, werden die Ablaufzeit und die includeSubDomains
-Direktive aktualisiert. Der Host wird ausschließlich anhand seines Domainnamens identifiziert. Eine IP-Adresse kann kein HSTS-Host sein. HSTS gilt für alle Ports des Hosts, unabhängig davon, welcher Port für die Anfrage verwendet wurde.
Bevor eine http
-URL geladen wird, prüft der Browser den Domainnamen gegen seine Liste von HSTS-Hosts. Wenn der Domainname eine nicht case-sensitive Übereinstimmung mit einem HSTS-Host ist oder eine Subdomain von einem ist, der includeSubDomains
spezifiziert hat, dann ersetzt der Browser das URL-Schema durch https
. Wenn die URL Port 80 angibt, ändert der Browser ihn zu 443. Jede andere explizite Portnummer bleibt unverändert, und der Browser stellt die Verbindung zu diesem Port über HTTPS her.
Wenn eine TLS-Warnung oder ein Fehler, wie ein ungültiges Zertifikat, bei der Verbindung zu einem HSTS-Host auftritt, bietet der Browser dem Benutzer keine Möglichkeit, die Fehlernachricht zu umgehen oder zu "überspringen", was die Absicht der strikten Sicherheit untergraben würde.
Hinweis:
Der Host muss den Strict-Transport-Security
Header nur über HTTPS senden, nicht unsicheres HTTP. Browser ignorieren den Header, wenn er über HTTP gesendet wird, um einen Man-in-the-Middle (MITM) Angriff zu verhindern, der den Header manipuliert, um vorzeitig zu verfallen oder ihn für einen Host hinzuzufügen, der HTTPS nicht unterstützt.
Ablauf
Jedes Mal, wenn der Browser einen Strict-Transport-Security
Header erhält, aktualisiert er die HSTS-Ablaufzeit des Hosts, indem er max-age
zur aktuellen Zeit hinzufügt. Die Verwendung eines festen Wertes für max-age
kann verhindern, dass HSTS abläuft, da jede nachfolgende Antwort die Ablaufzeit weiter in die Zukunft verschiebt.
Wenn der Strict-Transport-Security
Header in einer Antwort von einem Host fehlt, der zuvor einen gesendet hat, bleibt der vorherige Header bis zu seiner Ablaufzeit in Kraft.
Um HSTS zu deaktivieren, setzen Sie max-age=0
. Dies wird erst wirksam, wenn der Browser eine sichere Anfrage stellt und den Antwort-Header erhält. Sie können HSTS nicht über unsicheres HTTP deaktivieren.
Subdomains
Die includeSubDomains
Direktive weist den Browser an, die HSTS-Richtlinie einer Domain auch auf ihre Subdomains anzuwenden. Eine HSTS-Richtlinie für secure.example.com
mit includeSubDomains
gilt auch für login.secure.example.com
und admin.login.secure.example.com
. Aber sie gilt nicht für example.com
oder insecure.example.com
.
Jeder Subdomain-Host sollte Strict-Transport-Security
Header in seinen Antworten enthalten, selbst wenn die Superdomain includeSubDomains
verwendet, da ein Browser möglicherweise einen Subdomain-Host vor der Superdomain kontaktiert. Zum Beispiel, wenn example.com
den HSTS-Header mit includeSubDomains
enthält, aber alle bestehenden Links direkt zu www.example.com
gehen, wird der Browser nie den HSTS-Header von example.com
sehen. Daher sollte auch www.example.com
HSTS-Header senden.
Der Browser speichert die HSTS-Richtlinie für jede Domain und Subdomain unabhängig, unabhängig von der includeSubDomains
Direktive. Wenn sowohl example.com
als auch login.example.com
HSTS-Header senden, speichert der Browser zwei separate HSTS-Richtlinien, und sie können unabhängig ablaufen. Wenn example.com
includeSubDomains
verwendet hat, bleibt login.example.com
abgedeckt, falls eine der Richtlinien abläuft.
Wenn max-age=0
, hat includeSubDomains
keine Wirkung, da die Domain, die includeSubDomains
spezifiziert hat, sofort aus der HSTS-Host-Liste gelöscht wird; dies löscht nicht die separaten HSTS-Richtlinien jeder Subdomain.
Unsichere HTTP-Anfragen
Wenn der Host unsichere HTTP-Anfragen akzeptiert, sollte er mit einer permanenten Weiterleitung (wie Statuscode 301
) antworten, die eine https
URL im Location
Header enthält. Die Weiterleitung sollte den Strict-Transport-Security
Header nicht enthalten, da die Anfrage unsicheres HTTP verwendet hat, aber der Header muss nur über HTTPS gesendet werden. Nachdem der Browser der Weiterleitung gefolgt ist und eine neue Anfrage mit HTTPS gestellt hat, sollte die Antwort den Strict-Transport-Security
Header enthalten, um sicherzustellen, dass zukünftige Versuche, eine http
URL zu laden, sofort HTTPS verwenden, ohne eine Weiterleitung zu erfordern.
Ein Schwachpunkt von HSTS ist, dass es erst wirksam wird, nachdem der Browser mindestens eine sichere Verbindung zum Host hergestellt und den Strict-Transport-Security
Header erhalten hat. Wenn der Browser eine unsichere http
URL lädt, bevor er weiß, dass der Host ein HSTS-Host ist, ist die anfängliche Anfrage anfällig für Netzwerkangriffe. Das Preloading mildert dieses Problem.
Beispiel-Szenario für strenge Transportsicherheit
-
Zu Hause besucht der Benutzer
http://example.com/
zum ersten Mal. -
Da das URL-Schema
http
ist und der Browser es nicht in seiner HSTS-Host-Liste hat, erfolgt die Verbindung über unsicheres HTTP. -
Der Server antwortet mit einem
301 Moved Permanently
Redirect zuhttps://example.com/
. -
Der Browser stellt eine neue Anfrage, diesmal über HTTPS.
-
Die Antwort, die über HTTPS erfolgt, enthält den Header:
httpStrict-Transport-Security: max-age=31536000; includeSubDomains
Der Browser merkt sich
example.com
als HSTS-Host und dassincludeSubDomains
angegeben wurde. -
Einige Wochen später ist der Benutzer am Flughafen und entscheidet sich, das kostenlose Wi-Fi zu nutzen. Aber ohne es zu wissen, stellt er eine Verbindung zu einem bösartigen Zugangspunkt auf dem Laptop eines Angreifers her.
-
Der Benutzer öffnet
http://login.example.com/
. Da der Browser sichexample.com
als HSTS-Host merkt und dieincludeSubDomains
Direktive verwendet wurde, verwendet der Browser HTTPS. -
Der Angreifer interceptiert die Anfrage mit einem gefälschten HTTPS-Server, hat aber kein gültiges Zertifikat für die Domain.
-
Der Browser zeigt einen ungültigen Zertifikatfehler an und erlaubt dem Benutzer nicht, ihn zu umgehen, wodurch das Risiko vermieden wird, dass er sein Passwort an den Angreifer weitergibt.
Preloading Strict Transport Security
Google betreibt einen HSTS Preload-Service. Indem Sie die Richtlinien befolgen und Ihre Domain erfolgreich einreichen, können Sie sicherstellen, dass Browser nur über sichere Verbindungen zu Ihrer Domain verbinden. Während der Dienst von Google gehostet wird, verwenden alle Browser diese Preload-Liste. Es ist jedoch nicht Teil der HSTS-Spezifikation und sollte nicht als offiziell betrachtet werden.
- Informationen zur HSTS-Preload-Liste in Chrome: https://www.chromium.org/hsts/
- Konsultation der Firefox HSTS-Preload-Liste: nsSTSPreloadList.inc
Beispiele
Verwendung von Strict-Transport-Security
Alle gegenwärtigen und zukünftigen Subdomains werden für max-age
von 1 Jahr HTTPS sein. Dies blockiert den Zugriff auf Seiten oder Subdomains, die nur über HTTP bereitgestellt werden können.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Obwohl ein max-age
von 1 Jahr für eine Domain akzeptabel ist, wird ein Wert von zwei Jahren empfohlen, wie auf https://hstspreload.org erklärt.
Im folgenden Beispiel ist max-age
auf 2 Jahre gesetzt und wird mit preload
ergänzt, was erforderlich ist, um in die HSTS-Preload-Listen aller großen Webbrowser wie Chromium, Edge und Firefox aufgenommen zu werden.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Spezifikationen
Specification |
---|
HTTP Strict Transport Security (HSTS) # section-6.1 |
Browser-Kompatibilität
Siehe auch
- Funktionen, die auf sichere Kontexte beschränkt sind
- HTTP Strict Transport Security ist da! auf blog.sidstamm.com (2010)
- HTTP Strict Transport Security (Erzwungene HTTPS) auf hacks.mozilla.org (2010)
- HTTP Strict Transport Security Cheatsheet auf owasp.org
- HTTP Strict Transport Security auf Wikipedia
- HSTS Preload-Service