Fehlende HTTP Strict Transport Security

Praktisch jede Website läuft heute über HTTPS, und dennoch beginnt ein Browserbesuch auffällig oft mit einer unverschlüsselten Anfrage. Jemand tippt eine Adresse ohne Protokoll ein, klickt auf einen alten Link oder folgt einem jahrealten Lesezeichen. Genau auf diese eine erste Anfrage wartet ein Angreifer. Im Folgenden lesen Sie, wie HSTS dieses Fenster schließt und welche Einstellungen dabei schieflaufen.

Was ist HTTP Strict Transport Security?

HTTP Strict Transport Security (HSTS) ist ein HTTP-Header, mit dem ein Server den Browser anweist, diese Domain künftig ausschließlich über HTTPS aufzurufen. Der Browser merkt sich diese Anweisung für den angegebenen Zeitraum und wandelt fortan jede http://-Adresse dieser Domain in https:// um, noch bevor auch nur ein Byte ins Netz geht.

Der Unterschied zu einer gewöhnlichen Weiterleitung ist fein, aber entscheidend. Eine Weiterleitung ist eine Antwort des Servers: Der Browser muss also zuerst eine unverschlüsselte Anfrage senden, um zu erfahren, dass er auf HTTPS wechseln soll. HSTS ist eine Anweisung, an die sich der Browser erinnert: Es geht keine unverschlüsselte Anfrage mehr hinaus, um herauszufinden, dass sie nicht hätte hinausgehen dürfen.

Stellen Sie sich einen Empfang vor, an dem Besucher ihren Ausweis zeigen müssen. Eine Weiterleitung ist die Empfangskraft, die sagt: “Sie stehen jetzt drinnen, gehen Sie bitte kurz zurück und melden Sie sich ordentlich an.” HSTS ist das Schild an der Außenseite, das Besucher bereits gelesen hatten, bevor sie hineingingen. Im ersten Fall hat jemand schon in der Halle gestanden, im zweiten nicht.

Wie funktioniert ein Downgrade-Angriff?

Der Angriff spielt sich im Netzwerk ab: in einem öffentlichen WLAN, an einem kompromittierten Router oder bei einem zwischengeschalteten Anbieter. Der Angreifer muss keine Verschlüsselung brechen, er muss nur verhindern, dass sie überhaupt zustande kommt.

Verwundbar:

HTTP/1.1 301 Moved Permanently
Location: https://portal.example/anmelden

Auf den ersten Blick ist das korrekt: Der Server leitet Besucher sauber auf HTTPS weiter. Das Problem ist, dass der Nutzer, um diese Antwort zu erhalten, zunächst Folgendes senden musste:

GET /anmelden HTTP/1.1
Host: portal.example

Diese Anfrage geht in lesbarer Form über das Netz. Ein Angreifer, der dazwischensitzt, lässt die Weiterleitung nie ankommen. Stattdessen hält er die Verbindung zum Nutzer selbst über HTTP aufrecht, spricht auf der Rückseite sehr wohl HTTPS mit Ihrem Server und liest alles mit, was das Opfer eintippt: Benutzername, Passwort, Session-Cookie. Der Nutzer sieht eine funktionierende Anmeldeseite und bemerkt allenfalls, dass das Schloss fehlt.

Sicher:

HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Nach einem einzigen erfolgreichen HTTPS-Besuch merkt sich der Browser dies ein Jahr lang. Tippt der Nutzer danach portal.example in die Adresszeile, sendet der Browser sofort eine HTTPS-Anfrage; es gibt keine unverschlüsselte Anfrage mehr, die sich abfangen ließe. includeSubDomains weitet diese Regel auf jede Subdomain aus, was wichtig ist, weil ein vergessenes test.portal.example sonst eine offene Seitentür bliebe. Mit preload gelangt die Domain auf eine im Browser selbst hinterlegte Liste, sodass bereits der allererste Besuch geschützt ist.

Welche Auswirkungen hat fehlendes HSTS?

Der Schweregrad wird üblicherweise als niedrig bis mittel bewertet, weil der Angreifer eine Position im Netzwerkpfad benötigt. Diese Bedingung wiegt weniger schwer, als sie klingt: Ein öffentliches Netz in Zug, Hotel oder Café, ein nachgebildeter WLAN-Zugangspunkt oder ein kompromittiertes Heimgerät genügen.

Gelingt der Angriff, ist der Schaden allerdings vollständig. Der Angreifer liest alles mit, was über die Verbindung geht: Zugangsdaten, Session-Cookies, personenbezogene Daten und die Inhalte von Formularen. Zudem kann er die Antwort verändern, womit der Weg zu einer nachgebauten Anmeldemaske oder eingeschleustem Skriptcode offensteht. Da in diesem Szenario das Session-Cookie erbeutet wird, muss der Angreifer das Passwort nicht einmal kennen, um weiterzukommen.

Ein zu kurzer max-age-Wert schwächt den Schutz, ohne ihn ganz aufzuheben. Steht der Wert auf 30 Tagen, ist ein Nutzer, der sechs Wochen nicht vorbeigekommen ist, beim nächsten Besuch erneut verwundbar, also genau in dem Moment, in dem er die Adresse wieder eintippt.

Wie spürt man fehlendes HSTS auf?

Die Prüfung beginnt bei der HTTPS-Antwort: Gibt es einen Strict-Transport-Security-Header, und wenn ja, wie lang ist der max-age-Wert? Ein Wert unter einem Jahr verdient Aufmerksamkeit, ein Wert von null schaltet den Schutz aktiv ab.

Danach folgt die Untersuchung, die Scanner meist auslassen. Wird der Header auch auf Subdomains gesetzt, oder deckt includeSubDomains Domains ab, die selbst kein HTTPS anbieten? Leitet die HTTP-Fassung der Website korrekt auf HTTPS weiter, und geschieht das auf den richtigen Pfad? Wird der Header versehentlich nur auf der Startseite gesetzt und nicht auf der API oder dem Anmeldeendpunkt? Und steht die Domain auf der Preload-Liste, obwohl es noch eine Subdomain ohne Zertifikat gibt? AssistSec prüft bei einem Penetrationstest die vollständige Zertifikatskette und die Weiterleitungsstruktur und beurteilt, ob in der Praxis noch ein Pfad besteht, über den ein Nutzer unverschlüsselt mit Ihrer Anwendung sprechen kann.

Wie verhindert man fehlendes HSTS?

• Senden Sie Strict-Transport-Security bei jeder HTTPS-Antwort mit, mit max-age=31536000 als Richtwert.
• Ergänzen Sie includeSubDomains, sobald Sie sicher sind, dass alle Subdomains HTTPS unterstützen.
• Bauen Sie die Laufzeit schrittweise auf: kurz beginnen, prüfen, ob alles funktioniert, dann auf ein Jahr erhöhen.
• Leiten Sie weiterhin von HTTP auf HTTPS weiter; HSTS ersetzt diese Weiterleitung nicht, sondern ergänzt sie.
• Erwägen Sie die Aufnahme in die Preload-Liste für Domains, die dauerhaft und vollständig über HTTPS laufen.
• Setzen Sie den Header nie auf einer unverschlüsselten Antwort; Browser ignorieren ihn dort, was ein falsches Sicherheitsgefühl erzeugt.
• Überwachen Sie die Gültigkeit Ihrer Zertifikate aktiv, denn mit HSTS können Besucher einen Zertifikatsfehler nicht mehr wegklicken.
• Regeln Sie den Header zentral in Ihrem Webserver oder Proxy, damit neue Hosts und Routen ihn automatisch übernehmen.