Wenn ich bereits eine 301-Umleitung von allen inneren HTTP-Seiten zu HTTPS durchgeführt habe, warum sollte ich dann auch HSTS verwenden?
Schauen wir uns zuerst das Szenario mit einer 301-Umleitung an. Das Opfer sendet eine Anfrage an http://example.com (wie in den Kommentaren angegeben, kann dies an SSLStrip liegen oder daran, dass der Benutzer gerade example.com in das Feld eingegeben hat URL-Leiste und Browser standardmäßig HTTP). Wenn es keinen MitM-Angriff gibt, erhalten sie eine 301-Antwort zurück und werden zu https://example.com umgeleitet. Wenn es jedoch ein MitM gibt, kann der Angreifer einfach festlegen, dass das 301 nicht gesendet wird, sondern stattdessen eine (möglicherweise geänderte) Kopie der Site über HTTP bereitgestellt wird.
Der Schwachpunkt hierbei ist eine anfängliche HTTP-Verbindung (ohne TLS) wird erstellt, und der Angreifer kann diesen Datenverkehr ändern. Wenn Sie jedoch HSTS verwendet hätten, würde der Browser wissen (vorausgesetzt, das Opfer hat die Site zuvor besucht), dass die Seite immer über HTTPS bereitgestellt werden sollte - es wäre niemals eine HTTP-Anfrage gesendet worden, und der Browser würde lediglich eine Anfrage an senden https://example.com . Der Angreifer kann die TLS-Verbindung nicht mitm, daher wird der Angriff verhindert.
(Die Tatsache, dass Browser 301 Antworten zwischenspeichern, macht dies in der Praxis etwas komplizierter. Weitere Informationen hierzu finden Sie unter bonsaiviking's great Beantworten Sie oder diese Frage. Die Kurzgeschichte besagt, dass der zwischengespeicherte 301 möglicherweise etwas hilft, Sie aber nicht so weit bringt wie HSTS.)
HTTP Strict Transport Security (HSTS) dient der Sicherheit. HTTP 301 Permanent verschoben wird für die URL-Umleitung verwendet.
Die 301-Umleitung ist ein wichtiger Bestandteil der Bereitstellung einer HTTPS-Website. Als Teil des HTTP-Protokolls wird es von mehr Browsern als HSTS unterstützt. Es dient als primäres Mittel zum Aktualisieren einer Klartextverbindung zu HTTPS, zum Aktualisieren von Suchindizes und zum Vermeiden von Link Rot.
In vielen Fällen weisen diese beiden Methoden dieselbe Schwachstelle auf: die Erstanforderung wenn der Benutzer "example.com" in seinem Browser eingibt, wird Klartext gesendet. Wenn diese erste Anforderung in einem feindlichen Netzwerk mit einem aktiven Man-in-the-Middle (MITM) gestellt wird, kann die Antwort abgefangen werden und die Verbindung wird nicht auf eine sichere aktualisiert.
Es gibt viele Gründe, warum HSTS wichtig ist und eine große Sicherheitsverbesserung gegenüber einer Standard-301-Umleitung darstellt:
example.com/ umgeleitet wird, verwendet eine spätere Anforderung an example.com/somepage zunächst weiterhin HTTP und muss erneut umgeleitet werden. Für eine Site, die HSTS verwendet, ist nur eine Anforderung erforderlich, um die gesamte Site abzudecken. Erstens unterstützen einige alte Browser HSTS nicht. Sie müssen daher weiterhin HTTP zu HTTPS umleiten, das Flag sicher für alle Cookies setzen usw. Nun, nachdem dies gesagt wurde. .
Zusätzlich zu den oben aufgeführten guten Gründen gibt es einen weiteren Angriff, vor dem HSTS schützt, da das Weiterleiten von SSLStrip-Angriffen einer der Hauptzwecke von HSTS ist, einfache Weiterleitungen jedoch nicht.
Nehmen wir an, eine Site wird vollständig über HTTPS besucht. Der Benutzer ist sehr vorsichtig und fordert diese Site immer nur über HTTPS an. Keine Weiterleitung erforderlich. Es gibt kein HSTS, aber es gibt auch keine Links zur Site über ungesichertes HTTP, sodass der gesamte Datenverkehr mit der Site verschlüsselt ist.
Angenommen, die Site weist eine Sicherheitslücke auf, in der ein bestimmtes Cookie angezeigt wird (falls vorhanden) in die Seite ohne ordnungsgemäßes Entkommen (Cookie-basiertes XSS, selten, aber kaum unbekannt). Der Angreifer kann den HTTPS-Verkehr nicht lesen (geschweige denn ändern), möchte jedoch wirklich auf die Sitzung des Benutzers auf dieser HTTPS-Site zugreifen. Sie warten also darauf, dass der Benutzer eine andere Site über HTTP besucht, und ändern die Antwort von dieser Site so, dass sie eine unsichtbare Anforderung (möglicherweise ein Skript src) an http: // securesite enthält. com / (Ihre reine HTTPS-Site, aber stattdessen über HTTP). Was passiert als Nächstes:
https://securesite.com/ und der Angreifer kann keinen Datenverkehr lesen oder ändern. https: / /securesite.com/ , und die Anforderung wird erneut über HTTPS gesendet
sichere -Flag, sind in dieser anfänglichen unsicheren Anforderung enthalten. Der Angreifer kann sie an diesem Punkt sogar nur durch passives Abhören lesen. Das ist schlecht (und dies ist ein Grund, warum sensible Cookies immer das sichere -Flag haben müssen, auch wenn über eine unsichere Verbindung niemals auf die Site zugegriffen werden sollte). sicher sind, ist dieser Angriff sinnlos. Der Angreifer muss erneut manipulieren. Sie können die Antwort auf die unsichere Anforderung fälschen oder ändern. In diesem speziellen Fall würde der Angreifer der Antwort einen Set-Cookie -Header hinzufügen und ein Cookie in den Browser des Benutzers einfügen, das bei zukünftigen Anforderungen an securesite.com entweder über HTTP oder HTTPS gesendet wird. Mit dem hypothetischen XSS-Vektor auf Cookie-Basis (oder irgendetwas anderem, bei dem ein Cookie-Planting-Angriff Schaden anrichten kann) hat der Angreifer erfolgreich eine Site angegriffen, die der Benutzer sehr vorsichtig war Zugriff nur über HTTPS , nur weil es kein HSTS verwendet und eine Sicherheitsanfälligkeit aufweist, die ohne eine ungesicherte Verbindung nicht ausgenutzt werden kann.
). Das Wichtigste ist, dass die Richtlinie für Cookies mit gleichem Ursprung laxer ist als die Richtlinie mit gleichem Ursprung an anderer Stelle. Das heißt, es gibt keinen einzigen sicheren Kanal für Cookies, sie haben denselben Ursprung:
Client ---- Normales HTTP ---- > ServerClient -------- -HTTPS ---- > Server Natürlich kann das sichere Flag gesetzt werden, sodass ein Cookie-Wert so festgelegt werden kann, dass nur über HTTPS übertragen wird.
zB
Set-Cookie: foo = bar; sicherer
Client --> HTTP (keine Cookies) --> ServerClient --> HTTPS (Cookie: foo = bar) --> Server Der Server kann jedoch nicht wissen, ob ein Cookie mit dem Secure Flag gesetzt wurde.
z über normales HTTP
Set-Cookie: foo = bar
Client --> HTTPS (Cookie: foo = bar) --> Server Der Server befindet sich in dieser Situation:
Obwohl vom Server gesetzte Cookies über HTTPS sind nicht zu schnüffeln, ein MITM kann seine eigenen Werte in eine "sichere" Sitzung einfügen. Dies gilt auch dann, wenn Sie keinen einfachen HTTP-Dienst haben:
Client ---- Einfaches HTTP ---- > Kein serviceClient --------- HTTPS ---- > Server ... da ein MITM weiterhin eine einfache HTTP-Anforderung an Ihre Domain generieren und das Cookie einfügen kann:
Client ---- Plain HTTP ---- > MITM --> Kein ServiceClient --------- HTTPS ------------- > Server Dies kann führen zu einigen Angriffen, wenn Ihre Site einige Schwachstellen aufweist, die ansonsten möglicherweise nicht ausgenutzt werden können:
Wie oben beschrieben, können Angriffe im ssltrip -Stil ohne HSTS ausgeführt werden. sslstrip ist bis zu einem gewissen Grad darauf angewiesen, dass der Benutzer nicht bemerkt, dass es sich nicht um HTTPS handelt.
Siehe auch diese Antwort.
HSTS verwendet eine sandboxed clientseitige 307-Umleitung, sodass es den Server erst im expliziten https-Modus erreicht. Eine 301-Weiterleitung ist andererseits serverseitig, benötigt Ressourcen, Zeit zum Abschließen usw. Außerdem stapelt eine 301 Ihre [verkettete] Umleitungsanzahl, die im Allgemeinen der SEO-Verwässerung zugeschrieben wird ist im Allgemeinen die bessere Wahl aufgrund seiner clientseitigen + Sandbox-Natur. Bei einer sehr langen TTL im Cache besteht jedoch eine "Gefahr". Wenn ein SSL abläuft oder Sie in den http-Modus zurückkehren möchten, werden Benutzer gesperrt. Dies liegt daran, dass die zwischengespeicherte HSTS-TTL nur nach https sucht, Browser jedoch keine Websites mit einem abgelaufenen Zertifikat verwenden. Lassen Sie es also niemals ablaufen oder den Modus wechseln, ohne die HSTS-Cache-Zeit in den Wochen (oder Monaten) vor der Änderung auf 0 zu setzen :) Mit 301 müssen Sie sich darüber keine Sorgen machen, da dies nicht der Browser ist, der die Entscheidung trifft Weiterleiten oder nicht - Personen werden nicht gesperrt, wenn Sie den Server ändern.
Da HSTS beim ersten Besuch Ihrer Website immer noch eine Umleitung erfordert (es sei denn, wir sind uns so sicher, dass keine Fehler vorliegen, dass ein irreversibles Vorladen über die Registrierung gewagt werden kann), ist dies eine Trickfrage. Es gibt im Wesentlichen keinen Unterschied zwischen der Verwendung des HSTS-Headers und der Verwendung eines Umleitungsheaders.
Die einzige gute Lösung, die ich mir vorstellen kann, besteht darin, jedem DNS-Zonendatensatz einen Datensatztyp oder ein Flag hinzuzufügen, um anzugeben, dass diese Domäne HTTPS unterstützt ". Dann besteht keine Notwendigkeit für HSTS oder Umleitung. Der Browser weiß bereits, dass https unterstützt wird (von seiner DNS-Suche), sodass er (sofern nicht vom Benutzer außer Kraft gesetzt) die http des Benutzers in https umschreiben kann, bevor er überhaupt die erste Anforderung an den Remote-Server sendet.