Frage:
Ist das Posten von HTTP zu HTTPS eine schlechte Praxis?
Troy Hunt
2011-01-18 06:36:51 UTC
view on stackexchange narkive permalink

Unter der Annahme, dass SSL sowohl zur Verschlüsselung von Daten als auch dient, um die Identität und Legitimität der Website zu gewährleisten, sollte ein Anmeldeformular bereitgestellt werden auf einer über HTTP angeforderten Seite vermieden werden, auch wenn sie auf HTTPS veröffentlicht?

Die Frage bezieht sich auf einen Beitrag, den ich gestern über das Who is Who von schlechten Passwortpraktiken und einige von ihnen verfasst habe Das Feedback deutete darauf hin, dass es nicht in Ordnung war, das im Browser dargestellte Zertifikat vor der Authentifizierung sichtbar zu sehen, wenn das Formular tatsächlich sicher gesendet wurde.

Meiner Meinung nach ist SSL kurz, da Sie nicht nur die Möglichkeit verlieren, die Legitimität der Website zu überprüfen, bevor Sie Ihre Anmeldeinformationen übergeben, sondern auch nicht sicher sind, ob es sich um Posten über HTTPS. Ich bin mir bewusst, dass Twitter und Facebook diesen Ansatz verfolgen, aber sollten sie das tun? Übersehe ich hier etwas oder ist dies eine Praxis, von der abgeraten werden sollte?

Update: Am Ende habe ich das Ergebnis dieser Frage und die anschließende Diskussion im Blog-Beitrag detailliert beschrieben Bei SSL geht es nicht um Verschlüsselung

Vier antworten:
#1
+58
Tate Hansen
2011-01-18 06:43:11 UTC
view on stackexchange narkive permalink

OWASP-Status:

(wörtlich kopiert von http://www.owasp.org/index.php/SSL_Best_Practices)

Sichere Anmeldeseiten
Es gibt mehrere wichtige Überlegungen zum sicheren Entwerfen einer Anmeldeseite. Der folgende Text behandelt die Überlegungen in Bezug auf SSL.

Anmeldungen müssen auf einer SSL-Seite veröffentlicht werden Dies ist ziemlich offensichtlich. Der Benutzername und das Passwort müssen über eine SSL-Verbindung gesendet werden. Wenn Sie sich das Aktionselement des Formulars ansehen, sollte es https sein.

Anmeldeseite muss SSL verwenden Die tatsächliche Seite, auf der der Benutzer das Formular ausfüllt, muss eine HTTPS-Seite sein . Wenn dies nicht der Fall ist, kann ein Angreifer die Seite beim Senden an den Benutzer ändern und den Speicherort für die Formularübermittlung ändern oder JavaScript einfügen, das den Benutzernamen / das Kennwort während der Eingabe stiehlt.

Es muss vorhanden sein Keine SSL-Fehler- oder Warnmeldungen Das Vorhandensein einer SSL-Warnmeldung ist ein Fehler. Einige dieser Fehlermeldungen sind berechtigte Sicherheitsbedenken. andere desensibilisieren die Benutzer gegen echte Sicherheitsbedenken, da sie blind auf Akzeptieren klicken. Das Vorhandensein einer SSL-Fehlermeldung ist nicht akzeptabel - selbst wenn der Domänenname für das WWW nicht übereinstimmt, sollten

HTTP-Verbindungen getrennt werden. Wenn ein Benutzer versucht, eine Verbindung zur HTTP-Version der Anmeldung herzustellen Seite sollte die Verbindung verweigert werden. Eine Strategie besteht darin, HTTP-Verbindungen automatisch zu HTTPS-Verbindungen umzuleiten. Während dies den Benutzer auf die sichere Seite bringt, besteht ein anhaltendes Risiko. Ein Angreifer, der einen Mann im mittleren Angriff ausführt, kann die HTTP-Umleitungsantwort abfangen und den Benutzer auf eine andere Seite senden.

Wiederholen: Anmeldeseite muss SSL verwenden

Verwenden Sie HSTS, um HTTPS zu erzwingen
@danday74 Es ist erwähnenswert, dass der HSTS-Header ignoriert wird, wenn er über HTTP gesendet wird (da ein Angreifer den Header nach Belieben einfügen / entfernen kann). Sie müssen ihn daher mindestens einmal an eine HTTPS-Seite senden, selbst wenn Sie HSTS verwenden.Ganz zu schweigen davon, wann / ob der Header abläuft.
#2
+13
PulpSpy
2011-01-18 09:51:24 UTC
view on stackexchange narkive permalink

Es kann sinnvoll sein, hinzuzufügen, dass es automatisierte Tools gibt, mit denen genau das getan werden kann, was in den Best Practices von OWASP angegeben ist: "Ein Angreifer kann die Seite beim Senden an den Benutzer ändern und den Speicherort für die Formularübermittlung ändern ... "Der Link enthält eine Black Hat-Präsentation zum Angriff.

Nehmen Sie sich ein paar Stunden Zeit, um die anderen Tools und Artikel auf dieser Website zu überprüfen. Moxie ist wirklich ein interessanter Typ mit großartigen Einblicken in SSL und Sicherheit im Allgemeinen.
#3
+10
Rory McCune
2011-01-18 16:39:36 UTC
view on stackexchange narkive permalink

Zum Hinzufügen zu den bereits bereitgestellten Antworten. Es gab praktische Fälle, in denen Angreifer mit Nicht-HTTPS-Zielseiten die Site ändern und Benutzeranmeldeinformationen abrufen konnten. Dieses Beispiel ist das neueste, das ich gesehen habe. In diesem Fall wurde dies auf ISP-Ebene durchgeführt, aber ebenso von drahtlosen Hotspot-Anbietern oder von jedem, der die entsprechenden Tools zur Durchführung eines Man-In-The-Middle-Angriffs verwendet.

#4
-3
symcbean
2011-01-18 17:05:06 UTC
view on stackexchange narkive permalink

Technisch gesehen ist es immer noch sicher - Ihr Browser sollte Ihnen mitteilen, ob das Zertifikat nach dem SSL-Handshake nicht gefällt, aber bevor HTTP-Daten gesendet werden. Als Benutzer wäre ich jedoch sehr vorsichtig Eine Site, die mich auffordert, Authentifizierungsdetails anzugeben, bevor sie zu HTTPS gewechselt ist - ohne ein bisschen herumzuwühlen und etwas über das Thema zu wissen, weiß ich erst, nachdem ich die Informationen gesendet habe, ob der Ort, an den ich sie gesendet habe ist sicher (oder wo ich erwartet hatte).

Selbst wenn ich der Site vertraue, kann dieser Ansatz durch einen MITM-Angriff auf die HTTP-Seite untergraben werden.

Ihre Antwort widerspricht Ihrem ersten Satz: "Technisch ist es immer noch sicher". Das Problem ist, dass "sicher" hier verschiedene Bedeutungen haben kann.
Aber natürlich ist es technisch nur dann sicher, wenn die Site legitim ist und nicht manipuliert wurde, bevor die Anmeldeinformationen eingegeben wurden, die Sie nicht feststellen können, wenn kein Zertifikat sichtbar ist, oder?
Nein, technisch gesehen ist es immer noch unsicher, zumindest gegen Man-in-the-Middle-Angriffe. Die Seite wurde möglicherweise geändert und sendet möglicherweise Ihr Passwort an Timbuktu. Browser-Warnungen sind ** nicht ** wirksam, um solche Angriffe zu stoppen. Ihr letzter Satz ist korrekt, aber Ihr erster Absatz ist falsch.
@Troy - "sicher" schützt nicht nur die Vertraulichkeit des Transports, sondern auch die Authentifizierung usw.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...