Unsicherer JavaScript-Versuch, mit URL auf Frame zuzugreifen

112

Ich erhalte die folgende Fehlermeldung, wenn ich versuche, einen Hashwert für die übergeordnete URL von iframe festzulegen, die eine andere Domänen-URL enthält:

Unsicherer JavaScript-Versuch, auf Frame mit der URL "URL1" vom Frame mit der URL "URL2" zuzugreifen. Domänen, Protokolle und Ports müssen übereinstimmen.

Wie kann ich dieses Problem beheben?

— Atul
quelle

3

Bitte fügen Sie weitere Details, Code-Schnipsel, Fehlermeldungen und das von Ihnen verwendete Framework hinzu. Mehr Ausführlichkeit, weitere Details.

— fifigyuri

5

Was ist, wenn Sie g + 1, Facebook-ähnliche oder shre- und twitter-Social-Plugins implementieren, die in iframes geladen werden und denselben Fehler auslösen?

Die Frage ist, WARUM Facebook- und Google-Skripte sogar VERSUCHEN, auf meine Website-Elemente zuzugreifen.

— Sergio

124

Von einem untergeordneten Dokument unterschiedlicher Herkunft aus können Sie nicht auf die location.hashEigenschaft des oberen Fensters zugreifen , sondern die locationEigenschaft selbst festlegen .

Dies bedeutet , dass da die oberen Fenster Lage ist http://example.com/page/, anstatt das zu tun

parent.location.hash = "#foobar";

Sie müssen den Standort der Eltern kennen und tun

parent.location = "http://example.com/page/#foobar";

Da die Ressource nicht navigiert wird, funktioniert dies wie erwartet und ändert nur den Hash-Teil der URL.

Wenn Sie dies für die domänenübergreifende Kommunikation verwenden, würde ich empfehlen, stattdessen easyXDM zu verwenden.

— Sean Kinsey
quelle

13

Niemand hat dies als Antwort markiert und dennoch hat es 60 positive Stimmen. Dafür sollte es ein Abzeichen geben.

— Zachzurn

35

Wie würde das Abzeichen heißen? "Auf eine faule Person

— geantwortet

1

Hey @atul, sei nett und markiere diese Antwort als die beste. Seien Sie respektvoll mit den Konventionen, die es uns allen ermöglichen, vom Wissen anderer zu profitieren ...

— Clint Eastwood

13

Crossframe-Scripting ist nicht möglich, wenn die beiden Frames unterschiedliche Domänen haben -> Sicherheit.

Siehe dazu: http://javascript.about.com/od/reference/a/frame3.htm

Um Ihre Frage zu beantworten: Es gibt keine Lösung oder Problemumgehung. Sie sollten einfach Ihr Website-Design überprüfen, warum es zwei Frames aus verschiedenen Domänen geben muss, die die URL der anderen ändern.

— EvilMM
quelle

82

Dies ist eine häufige Anforderung, wenn eine Drittanbieteranwendung in Ihre Website eingebettet wird, insbesondere wenn Webdienste und dergleichen keine Option sind.

— Jacques

9

Ich habe die gleiche Fehlermeldung erhalten, als ich versucht habe, die Domain für iframe.src zu ändern.

Für mich bestand die Antwort darin, die Datei iframe.src in eine URL in der gleichen Domain zu ändern, die jedoch eine HTML-Umleitungsseite zur gewünschten Domain war. Die andere Domain wurde dann fehlerfrei in meinem Iframe angezeigt.

Lief wie am Schnürchen. :) :)

— Tommy
quelle

Könnten Sie genauer erläutern, was Sie hier getan haben?

— Devin G Rhode

Es wäre sehr hilfreich, wenn Sie es kurz erklären könnten.

— Madhusudhan

2

Funktioniert nicht in Chrome: Es überprüft nicht den src-Parameter, sondern die tatsächlich geladene URL. Der Redirect-Trick hilft also leider in keiner Weise :-(

— lucaferrario

3

Ich glaube, Tommy bezieht sich auf einen serverseitigen Proxy. Siehe z. B. benalman.com/projects/php-simple-proxy oder developer.yahoo.com/javascript/howto-proxy.html oder google.com/… oder die Lösung von René de Kat unter stackoverflow.com/a/11224975/27938

— Oskar Austegard

Das ist ordentlich. Aber es zeigt nur, wie trivial es im Allgemeinen ist, dies zu umgehen. Okay, nehmen wir an, dass ich ein böser böswilliger Hacker bin und domänenübergreifende Scripting-Angriffe ausführen möchte. Wahrscheinlich werde ich diese Tools kennenlernen und verwenden. Was die Sicherheitskorrekturen des Browsers betrifft, ist dies leicht so verzögert wie der IE, mit dem Sie Javascript nicht ohne Warnung lokal ausführen können. Löst kein Problem. Erstellt eine Reihe neuer.

— Yitzhak

6

Eine Lösung könnte darin bestehen, eine lokale Datei zu verwenden, die den Remote-Inhalt abruft

remoteInclude.php

<?php
$url = $_GET['url'];
$contents = file_get_contents($url);
echo $contents;

Der HTML

<iframe frameborder="1" id="frametest" src="/remoteInclude.php?url=REMOTE_URL_HERE"></iframe>
<script>
    $("#frametest").load(function (){       
    var contents =$("#frametest").contents();
});

1

Dies öffnet die Tür für Cross-Site-Scripting-Schwachstellen. Ein Beispiel für einen möglichen Angriff: 1. Ich erstelle auf myevilserver.com eine Seite, die genau wie Ihre Website aussieht, einschließlich eines Anmeldeformulars, das an myevilserver.com zurücksendet. 2. Ich versende Ihren Benutzern einen gefälschten Newsletter mit einem Link zu https: // yoursite.com/remoteInclude.php?url=myevilserver.com 3. Auf Ihrer Website wird ein Anmeldeformular angezeigt , das ich auf meinem Server erfasse .

— EricP

2

Eine mögliche Lösung besteht darin, remoteInclude.php alle URLs anhand einer vorab genehmigten Liste von Domains überprüfen zu lassen.

— EricP

Dies löst keine Schwachstellenprobleme bei Cross Site Scripting. Es gibt absolut nichts, was ich mit Javascript auf einer externen Website tun kann, was ich vom Server aus nicht tun kann. Dies behindert lediglich den Browser selbst und macht Web-Apps weniger nützlich, indem ein zusätzlicher Schritt eingeführt wird. Sie können all diese Dinge immer noch tun, wenn Sie über Ajax laden, Links neu schreiben und zurück posten. Wenn das nicht funktioniert, Remote-RPC über PHP oder eine andere Sprache. Es ist absurd, dass dies sogar ein Problem für den durchschnittlichen Codierer ist.

— Yitzhak

3

Ich habe festgestellt, dass die Verwendung der XFBML-Version des Facebook-Like-Buttons anstelle der HTML5-Version dieses Problem behoben hat. Fügen Sie den folgenden Code hinzu, an dem die Schaltfläche angezeigt werden soll:

<div id="fb-root"></div>
<script>(function (d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
    js = d.createElement(s); js.id = id;
    js.src = "//connect.facebook.net/en_GB/all.js#xfbml=1";
    fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

<fb:like send="true" layout="button_count" width="50" show_faces="false" font="arial"></fb:like>

Fügen Sie dies dann Ihrem HTML-Tag hinzu:

 xmlns:fb="http://ogp.me/ns/fb#"

— Luke Alderton
quelle

2

Was hat Facebook mit dieser Frage zu tun?

— Kukks

16

Weil Sie diesen Fehler auch auf Facebook-ähnlichen Schaltflächen erhalten und ich diese Seite bei der Suche nach einer Antwort gefunden habe, dachte ich, dass andere die Antwort benötigen könnten.

— Luke Alderton

1

Das Problem besteht darin, dass selbst wenn Sie einen Proxy erstellen oder den Inhalt laden und wie lokal einfügen, alle von diesem Inhalt definierten Skripts aus der anderen Domäne geladen werden und domänenübergreifende Probleme verursachen.

— user2345833
quelle