it-swarm.com.de

Sicherheit einer ersten Umleitung von http://example.com zu https://example.com

Angenommen, http://example.com/<foo> Leitet systematisch zu https://example.com/<foo> Weiter. Ich gebe http://example.com In die URL-Leiste meines Browsers ein und sehe, dass eine Seite geladen wird. In der URL-Leiste wird jetzt genau https://example.com/ Angezeigt (kein Unicode-Hack, kein Whitespace-Hack usw.). Ich überprüfe, ob dies der Fall ist (die meisten Benutzer werden dies nicht tun, gehe jedoch davon aus, dass dies in diesem Fall der Fall war). Nehmen Sie weiter an, dass mein Browser nicht anfällig für Fälschung der URL-Leiste ist. Nehmen Sie außerdem an, dass das SSL-Zertifikat gültig ist.

Kann ich in dieser Situation darauf vertrauen, dass meine Sitzung von nun an nicht mehr für einen Man-in-the-Middle-Angriff anfällig ist? Könnte ein MITM auf der anfänglichen HTTP-Verbindung etwas - ein Cookie, einen versteckten Frame, injiziert haben, was auch immer die nachfolgende scheinbare HTTPS-Sitzung gefährden würde?

Dies ist ein Teilfall von Wie sicher ist das Umleiten des Benutzers von http: //normal.bank.com nach https: //secure.bank.com ?, Ich bin nach mehr Details für diesen speziellen Fall.

Neben den hervorragenden Antworten von @ GZBK und @ Adnan habe ich auch daran gedacht, dass die Anwendung bei der Ausgabe von a anfällig für XSS ist Cookie-Wert.

Angenommen, der Cookie-Wert wird normalerweise nicht codiert ausgegeben, aber da der Cookie normalerweise über HTTPS gesetzt wurde und nicht MITM unterliegt, war dies keine Gefahr, da der Benutzer nur sich selbst angreifen konnte. Wenn jedoch die HTTP-Anforderung abgefangen wurde und das Cookie mit einem Exploit für diese Sicherheitsanfälligkeit XSS vergiftet wurde, kann dies in diesem Szenario ein möglicher Angriffsvektor sein.

Dies ist natürlich nicht die Nicht-HTTPS-Anforderung, einschließlich einer anfälligen Umleitung, da dieses Cookie gesetzt werden könnte, selbst wenn "example.com" Port 80 überhaupt nicht abgehört hat: Ein Angreifer könnte jede andere HTTP-Anforderung des Opfers MITM , leiten Sie sie zu "http://example.com" weiter, das der Angreifer ebenfalls abfängt und die Antwort zurückgibt, um den Benutzer auf seine ursprüngliche Website umzuleiten, jedoch erst, nachdem das Cookie "example.com" vergiftet wurde.

kann ich darauf vertrauen, dass meine Sitzung von nun an nicht mehr für Man-in-the-Middle-Angriffe anfällig ist?

Die einzige wirklich sichere Möglichkeit, über ein nicht vertrauenswürdiges Netzwerk zu navigieren, besteht darin, alle Protokolle im Browser außer HTTPS zu deaktivieren (z. B. einen lokalen Proxy konfigurieren, den Browser jedoch so einstellen, dass für alle Protokolle außer HTTPS ein ungültiger Port verwendet wird). HSTS kann helfen, aber wenn die erste Anforderung abgefangen wird (z. B. unter Verwendung der hier beschriebenen Technik, noch bevor Sie überhaupt daran gedacht haben, "example.com" Zu besuchen), sind Sie immer noch anfällig.

Update unten in Bezug auf neue Frage im Kommentar:

[Ich habe vergessen, den Kopfgeldkommentar einzugeben] Ich frage aus der Sicht eines Benutzers (obwohl es interessant ist zu wissen, was die Site/App auch tun sollte). Unter welchen Umständen leitet mich die Eingabe von example.com in die URL-Leiste des Browsers direkt zu https://example.com/ ? Unter welchen Umständen leitet mich die Eingabe von http://example.com/ direkt zu https://example.com/ ? Wenn zuerst eine Anfrage an http://example.com/ gestellt wird, welche schlechten Dinge können passieren und wie kann ich als Benutzer wissen, ob schlimme Dinge passieren? - Gilles

Wenn ein aktiver HSTS Datensatz für "example.com" (Entweder vorinstalliert oder wenn der Benutzer zuvor besucht hatte) vorhanden war und der Benutzer tippte Entweder "example.com" oder "http://example.com" in ihrer Adressleiste würden sie direkt zu "https://example.com" wechseln, ohne dass eine Anfrage über HTTP gestellt würde.

Wenn eine Webanwendung HSTS-Richtlinien an Benutzeragenten ausgibt, verhalten sich konforme Benutzeragenten wie folgt: Verwandeln Sie unsichere Links, die auf die Webanwendung verweisen, automatisch in sichere Links. (Zum Beispiel wird http://example.com/some/page/ vor dem Zugriff auf den Server in https://example.com/some/page/ geändert .) Wenn die Sicherheit der Verbindung nicht gewährleistet werden kann (z. B. das TLS-Zertifikat des Servers ist selbstsigniert), zeigen Sie eine Fehlermeldung an und erlauben Sie dem Benutzer nicht, auf die Webanwendung zuzugreifen.

Wenn es keinen HSTS Datensatz gäbe und der Benutzer "example.com" Oder "http://example.com" In seine Adressleiste eingeben würde, wäre zuerst eine unsichere Anfrage gemacht auf "http://example.com", was normalerweise mit dem Header "Location: https://example.com/" antworten würde. Dadurch lädt der Browser die HTTPS-URL. Wenn der Benutzer sicherstellen wollte, dass nichts injiziert oder geändert wurde und nur der Header "Location" zurückgegeben wurde, sollte er alle Statusinformationen löschen. Der Prozess dazu sollte wie folgt sein:

  1. Schließen Sie alle anderen Browserfenster und Registerkarten. Dadurch wird sichergestellt, dass keine anderen HTTP-Anforderungen MITM-fähig sind und an "example.com" Umgeleitet werden.
  2. Deaktivieren Sie JavaScript in ihrem Browser. Dadurch wird sichergestellt, dass kein Skript ausgeführt wird, das Cookies in einem Intervall setzt. Wenn beispielsweise eine Sicherheitsanfälligkeit XSS durch einen Cookie-Wert vorliegt, kann das injizierte Skript sicherstellen, dass der Cookie-Wert festgelegt bleibt, indem dies alle paar Sekunden zurückgesetzt wird. AKA ein Zombie-Cookie .
  3. Löschen Sie Cookies, lokalen Speicher und Browser-Plugin-Daten (z. B. lokales Flash/Silverlight). Dadurch werden die meisten Statusinformationen für die Site entfernt.
  4. Drücken Sie im Browser auf Aktualisieren. Dadurch wird sichergestellt, dass das aktuelle Laden der Seite kein POST war, da der Benutzer eine Warnmeldung erhalten würde. Das POST hat möglicherweise Inhalt in die Seite eingefügt, falls vorhanden) beliebige XSS Schwachstellen.
  5. Aktivieren Sie JavaScript bei Bedarf erneut.

Offensichtlich ist dies eine Menge zu erledigen, und es kann für sie einfacher sein, einfach die zuvor beschriebene Proxy-Technik zu verwenden, um HTTP zu deaktivieren und mit einem sauberen Browser zu beginnen (z. B. neue Incognito-Sitzung).

Wenn ein Benutzer über ein nicht vertrauenswürdiges Netzwerk surft, kann er niemals 100% sicher sein. Es gibt keine einfache Überprüfung auf Manipulationen, es sei denn, alles befindet sich in einem bekannten Zustand (daher entweder ausgehend von einem sauberen Zustand/HTTPS oder Entfernen aller Zustandsinformationen). Ja, sie könnten Cookies manuell überprüfen, aber mit cleveren Techniken könnte ein Angreifer das Cookie löschen, sobald das Skript in die Seite eingebettet wurde.

7
SilverlightFox

Soweit ich sehen kann, gibt es hier zwei Schwachstellen:

  • Das Secure Flag ist nicht gesetzt. Bei der ersten HTTP-Anforderung wird das Sitzungscookie entweder aus einer Sitzung gelöscht, die von der Instanz unter http://example.com Erstellt wurde, oder aus einer vorherigen Sitzung, die von der Instanz unter https://example.com Erstellt wurde. Dieselbe durchgesickerte Sitzungskennung wird wiederverwendet -> Der Angreifer hat Zugriff auf die Sitzung.

  • Die anfängliche HTTP-Anforderung wird abgefangen und die Antwort durch eine ersetzt, die ein Cookie mit einer Sitzungskennung für eine vom Angreifer gestartete Sitzung setzt. Nachfolgende Anfragen verwenden dasselbe Cookie wieder. Dies ist eine Form von Sitzungsfixierungsangriffe .

In beiden Fällen kann der Server beim Erreichen der HTTPS-Instanz nicht wissen, ob die vorherige Sitzung ungültig gemacht werden soll oder nicht, da die Sitzung die legitime sein kann, die vom Benutzer gestartet wurde.

Die einzige Lösung, die ich hier sehe, besteht darin, die Sitzung ungültig zu machen und neu zu erstellen, wenn eine Anforderung an https://example.com Gesendet wird, und dann bei nachfolgenden Anforderungen zusätzlich zum Sitzungscookie kryptografisch starke Token zu verwenden. Das Token muss einmal und nur einmal verwendet werden.

11
Adi

Wie oben erwähnt, müssen alle Cookies als sicher ( Owasp ) gekennzeichnet sein. Wenn Sie jedoch erwarten, dass Ihre Benutzer nur über SSL auf Ihre Website zugreifen, sollten Sie HTTP Strict Transport Security (HSTS - - aktivieren) Wikipedia ).

Der erste stellt sicher, dass kein Cookie über eine eindeutige HTTP-Verbindung gesendet wird, der zweite stellt sicher, dass jeder kompatible Browser nach einem ersten Erstzugriff immer HTTPS verwendet, um auf die Website zuzugreifen (selbst wenn der Benutzer HTTP eingibt, wird der Browser dies tun automatisch durch HTTPS ersetzen, ohne eine HTTP-Anfrage an den Server zu senden).

11
WhiteWinterWolf

Da die erste Anfrage über HTTP gesendet wurde; Es ist eine große Anzahl möglicher Angriffsvektoren verfügbar, die nicht von Cookies oder dem Sitzungsstatus abhängen und von einer nachfolgenden Umleitung zu HTTPS selbst mit einem vom Server bereitgestellten HSTS-Header nicht betroffen wären.

Obwohl ich kein Vollzeit-Web-Sicherheitsspezialist bin, finden Sie hier eine Liste möglicher Angriffe, die möglich sind, wenn ein Angreifer die ursprüngliche HTTP-Anforderung MITM kann.

1) Senden Sie 301/302-Weiterleitungen an Zwischen-URLs, um Malware außerhalb des Browsers einzurichten/zu installieren. Dies kann Keylogger usw. einschließen. Sehr wertvoll, da der Angreifer Opfer, die zu einem Ort von Interesse gehen, "auswählen" kann. Wenn die Malware auf dem Ziel bereitgestellt wird, wird erwartungsgemäß eine endgültige Browserumleitung an den Client gesendet, und der Film wird fortgesetzt, als wäre nichts passiert.

2) Verwenden Sie dasselbe Fahrzeug, um den Browser selbst anzugreifen. Hier besteht für den Angreifer die Möglichkeit, browserspezifische Aktionen wie die Installation eines böswilligen Plugins auszuführen.

3) Wie oben, aber alle verfügbaren Lücken ausnutzen, um die Browserkonfiguration zu ändern. Dies könnte verwendet werden, um einen Informationsverlust über einen verdeckten Kanal wie Suchhinweise oder die Vervollständigung von Schlüsselwörtern zu ermöglichen. Oder kombinieren Sie dies mit Option 1 und konfigurieren Sie den Browser so, dass SSL durch lokal ausgeführten Code als Proxy verwendet wird.

4) Laden Sie die Ziel-SSL-Seite in einen Iframe und nutzen Sie XSS-Schwachstellen aus, um Sitzungsanmeldeinformationen abzurufen und auszunutzen, sobald sich das Opfer anmeldet.

In den oben genannten Szenarien gibt es eine Vielzahl von Schwierigkeiten, die alle mehr oder weniger auf Schwachstellen in bestimmten Browserversionen beruhen. Viele der Szenarien sind möglicherweise schwieriger als andere einfachere Angriffsmethoden. Es ist nützlich, fokussierte Exploits in Abhängigkeit von den verfügbaren Informationen in den Headern der ursprünglichen Anforderung einzusetzen, z. B. User-Agent, die attraktiv sein könnten.

Ich bin mir sicher, dass es noch andere große Kategorien von Angriffen gibt, die mir fehlen, aber dies ist ein Anfang der Gefährdung, die eine erste HTTP-zu-HTTPS-Sitzung eröffnen kann.

1
bizzyunderscore

Nachdem Sie davon ausgegangen sind, dass die SSL-Verbindung mit der richtigen Domäne hergestellt wurde (und vorausgesetzt, dass weder Ihr Server noch der Browser Schwachstellen aufweisen), hat der Benutzer über Ihr SSL-Zertifikat und seine vertrauenswürdigen Stammzertifikate überprüft, von welcher Seite er geladen hat Ihr Server ist ohne Manipulation angekommen.

Ich sehe die folgenden Fallstricke:

  1. Ein Man-in-the-Middle-Angriff ist offensichtlich möglich, wenn der Interceptor Ihr SSL-Zertifikat fälschen kann. Wenn Sie es also geteilt haben (mit Ihrem CDN? Mit dem Schurkenadministrator bei Ihrem Webhoster? Mit dem Kollegen, dem gesetzlich untersagt ist, zuzugeben, dass er für die Schlüssel vorgeladen wurde?), Ist dies tatsächlich ein möglicher Angriffsvektor. Es kann auch vorkommen, dass Sie zuerst schwache Schlüssel generiert haben (möglicherweise war die Entropie Ihres Systems niedrig oder Sie haben einen defekten Zufallszahlengenerator verwendet?).

  2. Möglicherweise ist keine einzige der Stammzertifizierungsstellen, für die der Browser als vertrauenswürdig konfiguriert ist, gefährdet. Beachten Sie, dass es in der Regel viele, viele davon gibt und nur ein Kompromiss erforderlich ist, damit der Mann in der Mitte ein scheinbar gültiges SSL-Zertifikat für Ihre Domain fälschen kann. Beachten Sie auch, dass einige Benutzer möglicherweise nach Lust und Laune ihres Anbieters (wie Microsoft) bei Bedarf neue Stammzertifizierungsstellenzertifikate pushen und theoretisch jeden (rechtmäßigen?) Man-in-the-Middle-Angriff von Microsoft (oder einer der Zertifizierungsstellen) zulassen ) kann zur Unterstützung überredet werden. Wir können natürlich hoffen, dass nur die Guten so viel Macht über Unternehmen haben.

  3. Selbst scheinbar nicht verwandte Sicherheitslücken können offensichtlich das gesamte Argument negieren, selbst diejenigen, die eher als Feature als als Fehler bezeichnet werden können: Stellen Sie sich vor, der Mann in der Mitte bedient zunächst eine Webseite über HTTP, die den Browser veranlasst, zur Vollbildanzeige zu wechseln, und imitiert dann ein typisches Browserfenster. Wird Ihr hypothetischer, überaus fleißiger Benutzer feststellen, dass die Adressleiste und ihr Inhalt nur eine aufwändige Emulation der Adressleiste seines Browsers sind ...?

1
pyramids