Das IFRAMEElement kann ein Sicherheitsrisiko darstellen, wenn Ihre Site in eine IFRAMEfeindliche Site eingebettet ist . Google "Clickjacking" für weitere Details. Beachten Sie, dass es keine Rolle spielt, ob Sie verwenden <iframe>oder nicht. Der einzige wirkliche Schutz vor diesem Angriff besteht darin, einen HTTP-Header hinzuzufügen X-Frame-Options: DENYund zu hoffen, dass der Browser seinen Job kennt.
Darüber hinaus kann das IFRAME-Element ein Sicherheitsrisiko darstellen, wenn eine Seite Ihrer Website eine XSS-Sicherheitsanfälligkeit enthält, die ausgenutzt werden kann . In diesem Fall kann der Angreifer den XSS-Angriff auf jede Seite innerhalb derselben Domäne erweitern, die zum Laden innerhalb einer <iframe>Seite mit XSS-Sicherheitsanfälligkeit überredet werden kann . Dies liegt daran, dass Inhalte desselben Ursprungs (derselben Domäne) auf das übergeordnete Inhalts-DOM zugreifen dürfen (praktisch JavaScript im "Host" -Dokument ausführen). Die einzige wirkliche Schutzmethode vor diesem Angriff besteht darin, einen HTTP-Header hinzuzufügen X-Frame-Options: DENYund / oder alle vom Benutzer übermittelten Daten immer korrekt zu codieren (dh niemals eine XSS-Sicherheitslücke auf Ihrer Site zu haben - leichter gesagt als getan).
Das ist die technische Seite des Problems. Darüber hinaus gibt es das Problem der Benutzeroberfläche. Wenn Sie Ihren Benutzern beibringen, darauf zu vertrauen, dass sich die URL-Leiste beim Klicken auf Links nicht ändern soll (z. B. wenn Ihre Website einen großen Iframe mit dem gesamten tatsächlichen Inhalt verwendet), werden die Benutzer auch im Falle der tatsächlichen Sicherheit in Zukunft nichts bemerken Verletzlichkeit. Beispielsweise könnte Ihre Site eine XSS-Sicherheitsanfälligkeit aufweisen, die es dem Angreifer ermöglicht, Inhalte aus feindlichen Quellen in Ihren Iframe zu laden. Niemand konnte den Unterschied feststellen, da die URL-Leiste immer noch mit dem vorherigen Verhalten identisch ist (sich nie ändert) und der Inhalt "gültig" aussieht, obwohl er von einer feindlichen Domäne stammt, die Benutzeranmeldeinformationen anfordert.
Wenn jemand behauptet, dass die Verwendung eines <iframe>Elements auf Ihrer Website gefährlich ist und ein Sicherheitsrisiko darstellt, versteht er nicht, was das <iframe>Element tut, oder er spricht über die Möglichkeit <iframe>verwandter Schwachstellen in Browsern. Die Sicherheit des <iframe src="...">Tags ist gleich <img src="..."oder <a href="...">solange keine Schwachstellen im Browser vorhanden sind. Und wenn es eine geeignete Verwundbarkeit ist, könnte es möglich sein , sie auszulösen auch ohne <iframe>, <img>oder <a>Element, so ist es nicht wert für dieses Problem betrachten.
Beachten Sie jedoch, dass Inhalte <iframe>von standardmäßig die Navigation auf oberster Ebene initiieren können . Das heißt, Inhalte innerhalb von <iframe>dürfen automatisch einen Link über den aktuellen Seitenstandort öffnen (der neue Speicherort wird in der Adressleiste angezeigt). Die einzige Möglichkeit, dies zu vermeiden, besteht darin, ein sandboxAttribut ohne Wert hinzuzufügen allow-top-navigation. Zum Beispiel <iframe sandbox="allow-forms allow-scripts" ...>. Leider deaktiviert Sandbox auch immer alle Plugins. Beispielsweise können Youtube-Inhalte nicht in einer Sandbox gespeichert werden, da der Flash Player weiterhin zum Anzeigen aller Youtube-Inhalte erforderlich ist. Kein Browser unterstützt die Verwendung von Plugins und die gleichzeitige Nichtzulassung der Navigation auf oberster Ebene.
Beachten Sie, dass dies X-Frame-Options: DENYauch vor Rendering-Side-Channel-Angriffen schützt, bei denen Inhalte über den Ursprung hinweg gelesen werden können (auch als " Pixel Perfect Timing Attacks " bezeichnet).