Frage:
Gibt es Sicherheitsprobleme beim Einbetten eines HTTPS-Iframes in eine HTTP-Seite?
Yahel
2010-11-30 23:13:04 UTC
view on stackexchange narkive permalink

Ich habe gesehen, dass Websites HTTPS-Iframes auf HTTP-Seiten platziert haben.

Gibt es Sicherheitsbedenken? Ist es sicher, private Informationen wie Kreditkartendaten in einem solchen Schema zu übertragen (wobei die Informationen nur auf dem HTTPS-Iframe-Formular und nicht auf der übergeordneten HTTP-Seite abgelegt werden)?

Siehe auch https://security.stackexchange.com/q/38317/16960
Sechs antworten:
user502
2010-11-30 23:35:09 UTC
view on stackexchange narkive permalink

Wenn nur der Iframe https ist, kann der Benutzer die URL, auf die er verweist, nicht trivial sehen. Daher kann die http-Quellseite so geändert werden, dass der Iframe an eine beliebige Stelle verweist. Das ist so ziemlich eine Game-Over-Sicherheitslücke, die die Vorteile von https beseitigt.

+1 für den Hinweis auf die Bedeutung der * Serverauthentifizierung *, die häufig als Vorteil von SSL vergessen wird.
Ich erkenne, dass dies eine alte Frage ist, aber ich hatte gehofft, jemand könnte erklären, wie HTTPS auf der Ursprungsseite ein Problem eines Schurkenskripts löst, das den Speicherort des Iframes ändert?Wenn die Ursprungsseite HTTPS ist, kann es sein, dass ein Rogue-Skript das Iframe-Ziel ändert, nicht wahr?
@MattJames, Wenn die Ursprungsseite ebenfalls HTTPS ist, kann sie während der Übertragung nur geändert werden, wenn das MitM über ein gültiges Zertifikat für die Domäne verfügt (was nur passieren sollte, wenn die Zertifizierungsstellen ihre Arbeit nicht ausführen).Sie können jedoch weiterhin die ursprüngliche HTTP -> HTTPS-Last abfangen und an eine von ihnen kontrollierte Domäne umleiten.Benutzer können dies anhand der URL und des Zertifikats erkennen, die beide nur für den obersten Frame angezeigt werden.Allerdings würden die meisten Benutzer dies wahrscheinlich nicht bemerken, was ein Grund dafür ist, dass Konten manchmal kompromittiert werden.
Die Annahme ist natürlich, dass der Angreifer im Netzwerk sitzt.Wenn sie die Quellseite auf dem Server so ändern können, dass sie Schurkencode enthält, sind alle Wetten ungültig.Wenn sie ein Skript erhalten, mit dem der im Browser des Benutzers installierte Seiteninhalt geändert werden kann, sind sie ebenfalls anfällig.(Also müssen Leute, die Greasemonkey / Tampermonkey / etc verwenden, aufpassen, obwohl dies wiederum viele nicht tun.)
goodguys_activate
2010-12-01 01:01:06 UTC
view on stackexchange narkive permalink

iFrames setzt die innere HTTPS-Site in älteren Browsern zahlreichen Javascript- und Cookie-Angriffen aus und kann in neueren Browsern Probleme verursachen.

Um dies zu beheben, suchen Sie unter "Frame Busting" nach, ob iFrames verwendet werden. Betrachten Sie diese Lösung in StackOverflow:

https://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed

In diesem Code können Sie erkennen, ob iFrames verwendet werden, und alternative Inhalte anbieten, um den Benutzer auf die richtige Site zu leiten.

Paul
2010-12-01 01:18:20 UTC
view on stackexchange narkive permalink

Ein HTTPS-Iframe innerhalb einer Seite, die über HTTP bereitgestellt wird, ermöglicht es dem Benutzer nicht, sicher zu sein, dass er tatsächlich die HTTPS-Verbindung verwendet, die er erwartet erwartet. Daher kann der Iframe möglicherweise in einem einfachen Angriff wie einer Iframe-Injektion entführt werden. Dies würde unter anderem das Ernten von Passwörtern ermöglichen. Ein solcher Angriff kann durch einen Trojaner, einen Virus oder einfach durch den Besuch einer schädlichen Website beginnen.

symcbean
2010-12-01 22:06:35 UTC
view on stackexchange narkive permalink

Ja, während die neuesten Browser die SSL-Teile ordnungsgemäß sandboxen, untergraben Sie alle Funktionen, die dem Browser-Chrome hinzugefügt wurden, um dem Benutzer Feedback zum Inhalt zu geben. Ich jedenfalls würde keine vertraulichen Informationen bereitstellen, ohne die in meinem Browser angezeigte URL zu überprüfen.

Dominique
2011-06-04 02:38:00 UTC
view on stackexchange narkive permalink

Zusätzlich zu den bereits angegebenen möglichen Hijacking-Szenarien können unter IE6 / 7 Probleme auftreten, wenn Sie auf eine HTTP- oder HTTPS-Seite verweisen, für die eine Anmeldung erforderlich ist. Grundsätzlich erwarten die Cookies von der Iframe-Seite, dass Sie dasselbe Protokoll (HTTP oder HTTPS) verwenden. Wenn also die Seite, auf die Sie den Iframe setzen, HTTP anstelle von HTTPS verwendet, kann der Benutzer dies nicht Anmelden.

Diese Antwort scheint durcheinander zu sein. Ich bin mir nicht sicher, was Sie sagen wollen oder auf welches Problem Sie anspielen.
Cookies werden nicht zwischen http und https geteilt
gnasher729
2019-10-19 18:16:23 UTC
view on stackexchange narkive permalink

Jede http-Anfrage bedeutet zwei Dinge: Erstens können Hacker sowohl die Anfrage als auch die Antwort abhören und lesen. Zweitens können Hacker möglicherweise eine andere Website als die ursprüngliche zurückgeben.

Wenn ich also über http auf Ihre Website zugreife und einen https-Link zurückerhalte, erfahren Hacker möglicherweise etwas über diesen https-Link, aber insgesamt ist er nicht weniger sicher als ein http-Link.

Es gibt jedoch keinerlei Garantie dafür, dass ich Ihre Website erhalten habe und keine von einem Hacker bereitgestellte. Damit der https-Frame möglicherweise nicht einmal auf der richtigen Site vorhanden ist, sondern nur auf der gehackten. Und es gibt überhaupt keine Garantie, wohin es zeigt, daher überhaupt keine Sicherheit.

Sobald Sie mit http beginnen, ist das Spiel aus Sicherheitsgründen beendet.



ⓘ
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...