Zusammenfassend zu den Kommentaren (und durch Ersetzen meiner vorherigen Antwort): Solange sslstrip möglich ist, kann sich der Angreifer als Benutzer ausgeben und die Sitzung steuern, während der Browser glaubt, dass der Benutzer die Sitzung steuert. Nur HSTS kann sslstrip verhindern, und nur HSTS-Preload kann sslstrip bei der ersten Anforderung verhindern (bevor ein HSTS-Header abgerufen wird).

Daher sollte die HSTS-Vorladung der richtige Weg sein, wie in der Antwort von Benoit Esnard richtig dargelegt.

Das Problem ist, dass es Monate dauern kann, bis eine neue Domain verfügbar ist, da eine aktualisierte Liste nur mit einer neuen Version des Browsers geliefert wird (zumindest bei Google Chrome).

Mit anderen Worten: Es gibt keine Lösung, die innerhalb kurzer Zeit implementiert werden kann.

Senden Sie Ihre Website an die HSTS-Preload-Liste.

Die HSTS-Preload-Liste ist eine Liste von Hostnamen, die in Browser eingebettet sind, damit diese wissen, welche Websites als HTTPS gecrawlt werden müssen Nur, um eine Nicht-HTTPS-Anforderung zu verhindern.

Was Sie beschreiben, wird als Sitzungsfixierungsangriff (Wikipedia-Link) bezeichnet.

Kurz gesagt, das Problem besteht darin, dass der Angreifer Ihnen ein Sitzungskennungs-Cookie geben kann. Sie melden sich mit diesem Cookie an und der Server verknüpft Ihre Identität mit diesem Cookie.

Der Angreifer kennt Ihr Sitzungs-ID-Cookie weiterhin und kann so tun, als wären Sie mit dem Server verbunden. Angriff abgeschlossen.

Um sich dagegen zu verteidigen, muss der Server das Sitzungs-ID-Cookie ändern, wenn sich jemand anmeldet. Der Angreifer hat ein veraltetes wertloses Cookie und kann nichts tun.

Nicht bei allen Webframeworks können Sie das Sitzungscookie ändern. Wenn dies ein Problem ist, können Sie zu diesem Zweck ein anderes Cookie verwenden, ein separates "authentifiziertes Cookie", von dem das Framework nichts weiß. Auch dieses Cookie muss bei jedem Login geändert werden.

Da es keine vollständige Möglichkeit gibt, Clients davon abzuhalten, eine Verbindung zu HTTP herzustellen, möglicherweise mit Cookies ... besteht unsere Herausforderung darin, Möglichkeiten zu finden, um die Häufigkeit zu verringern.

Ein Ansatz ist HTTP überhaupt nicht zu unterstützen. Lassen Sie alle HTTP-Anforderungen eine Zeitüberschreitung (keine Umleitung, nichts). Dies verringert die Wahrscheinlichkeit, dass andere Websites auf Ihre HTTP-Adresse verlinken, da solche Links nicht funktionieren. Mit der Zeit wird hoffentlich jeder, der auf Ihre Website verlinkt, direkt auf HTTPS verlinken.

Sie können nicht verhindern, dass die Cookies beim ersten Mal über HTTP gesendet werden. Sie können jedoch Maßnahmen ergreifen, um den dadurch verursachten Schaden zu minimieren. Das Grundprinzip besteht darin, dass Sie niemals etwas ehren, das über HTTP übermittelt wurde. Wenn Sie vertrauliche Informationen im Klartext erhalten, behandeln Sie diese Informationen als gefährdet.

Richten Sie Ihre Site so ein, dass sie von HTTP zu HTTPS umleitet Starten Sie das Senden von Strict-Transport-Security-Headern. (Sie müssen nicht vorab laden, bis Sie gut und bereit sind. Was ich gleich sagen werde, funktioniert trotzdem.)

Wenn Sie dann Cookies sehen, die über Klartext-HTTP gesendet werden, machen Sie alle ungültig dieser Cookies auf der Serverseite. Versuchen Sie zu diesem Zeitpunkt nicht, sie aus dem Cookie-Glas des Browsers zu entfernen, da dies aus mehreren Gründen nicht garantiert funktioniert (eine Klartext-HTTP-Antwort kann Cookies mit dem Tag "Sicher" nicht manipulieren, ältere Browser ignorieren möglicherweise max-age = 0 Der Mann in der Mitte könnte Set-Cookie vollständig entfernen, um das Opfer mit dem kompromittierten Cookie zu halten. Aber ehren Sie sie nicht, wenn sie in einer nachfolgenden HTTPS-Anfrage erscheinen. Stellen Sie zu diesem Zeitpunkt (dh nur, wenn Sie einen sicheren Kanal eingerichtet haben) ein neues Sitzungstoken aus und fordern Sie den Benutzer auf, sich erneut anzumelden.

Wenn Sie Ihr Anmeldeformular em sehen > Wenn Sie im Klartext eingereicht werden, machen Sie nicht nur das Sitzungscookie ungültig, sondern sperren Sie das Konto. Leiten Sie das Formular zur Wiederherstellung, Anmeldung oder Registrierung des Kontos nicht von HTTP zu HTTPS um. Geben Sie stattdessen eine Fehlermeldung aus und weisen Sie den Menschen an, die URL von Hand zu korrigieren (es ist wie ein Captcha, dient jedoch dazu, das Umschreiben von URLs in sslstrip zu umgehen ;-). Und jede Seite, auf die nur angemeldete Benutzer zugreifen sollten, sollte beim Zugriff über Klartext auf die Startseite und nicht auf HTTPS selbst umleiten.

Stellen Sie außerdem sicher, dass Ihre Sitzungscookies sowohl nicht fälschbar als auch bedeutungslos sind. Die meisten Web-Frameworks erledigen dies heutzutage automatisch für Sie. Wenn Sie jedoch keine haben, funktioniert am einfachsten Folgendes: Jedes Sitzungscookie ist eine große Zufallszahl (64 Bit könnten ausreichen, 128 sind definitiv genug), die generiert wird durch ein kryptografisch sicheres RNG sowie einen Nachrichtenauthentifizierungscode, der diese Nummer signiert. Sie können hierfür einen symmetrischen MAC verwenden, da das Cookie nur von der Site authentifiziert werden muss, die dieselbe Entität ist, die den MAC ausgestellt hat, sodass es beide Male dasselbe Geheimnis kennt. Wenn ein Cookie mit einem ungültigen MAC eingeht, ignorieren Sie es , unabhängig davon, wie Sie es erhalten haben - tun Sie so, als hätten Sie es überhaupt nicht erhalten. (Dies ersetzt sogar die Regel zum Ungültigmachen von Cookies, die über HTTP eingehen. Sie möchten nicht, dass der Angreifer Personen durch Fälschen von Anforderungen zum Abmelden zwingen kann.) Wenn der MAC jedoch gültig ist, verwenden Sie die Zufallszahl als Schlüssel zu einer Datenbanktabelle, in der alle mit einer Benutzersitzung verbundenen tatsächlichen Informationen aufgezeichnet werden.

Es wird außerdem empfohlen, erst dann Cookies auszugeben, wenn jemand versucht, sich anzumelden MITM, um ein gültiges Cookie in die Hände zu bekommen, und es erleichtert Ihnen auch die Einhaltung der DSGVO.

Nachdem ich die Diskussion über die anderen Antworten gelesen habe, stelle ich jetzt fest, dass OP sich mit einem ganz bestimmten Szenario befasst: Ein neuer Benutzer auf der Site greift zum ersten Mal über ein Man-In darauf zu the-middle, der HTTPS beendet, HSTS entfernt, alle Links neu schreibt und die Site unverschlüsselt an den hypothetischen neuen Benutzer weiterleitet. In der Tat ist das einzige, was möglicherweise helfen kann, die HSTS-Vorlast. Ohne HSTS-Vorladung wird das Konto des neuen Benutzers sozusagen "kompromittiert" geboren, und der Angreifer weiß alles darüber: nicht nur das Sitzungscookie, sondern auch den Benutzernamen und das Kennwort. und die E-Mail-Adresse, die für die Wiederherstellung des Kontos verwendet wird, sowie alle persönlichen Informationen, die das Opfer eingegeben hat. Dies ist böse und leider plausibler als Sie vielleicht denken.

Wenn Sie jedoch nur eine Chance haben, mit dem Benutzer über einen Kanal zu interagieren, der nicht aktiv manipuliert wird, können Sie HSTS und drücken Sichere Sitzungscookies und alle oben genannten Ratschläge sind hilfreich.