XSS // Variablen an iFrame durchreichen (ohne Parameter der iFrame Source)

[Abraxax]

Hallo zusammen.

Ich schreibe einen iFrame mittels JS in Seite A und lade von Seiten B den iFrame-Source nach.

Code auf example-server-A ...

server_a_var1 = 'var1';
server_a_var2 = 'var2';
document.write('<iframe id="iframeID" src="" .... ></iframe>');
document.getElementById('iframeID').src = 'http://example-server-B.com/file.html';

Code auf example-server-B ...

file.html

document.write(parent.server_a_var1);
document.write(parent.server_a_var2);

Leider verhindert das Cross-Site-Scripting, dass ich in file.html die Variablen von Server A auslesen kann. Ist ja soweit auch nachvollziehbar.

Ich muss/will aber Variablen von meinem Hauptdokument an das iFrame geben. Aktuell mache ich es durch Anhängen an den URL und Auslesen des Querystrings. Aber ein URL ist ja auch begrenzt was die erlaubte Länge angeht.

Da die übergebenen Parameter länger als erlaubt sein können, suche ich nach einer anderen Lösung.

Habt ihr eine Idee?

Thx
Haxe

[wahsaga]

POST?
SCRIPT-Element mit externer source?

[reok]

Leider beschreibst du nicht, was genau du versuchst mit dieser Technik zu realisieren. Sonst könnte man vielleicht Alternativen aufzeigen.

Außerdem ist mir nicht ganz klar, was du mit "Anhängen an den URL und Auslesen des Querystrings" meinst. Setzt du die iFrame-URL ständig neu, wenn sich ein Parameter ändert? So dass auch die iFrame-Seite neu geladen wird?

Im Endeffekt also in etwa diesen Aufruf, sobald sich eine Variable auf Seite A ändert:
document.getElementById('iframeID').src = 'http://example-server-B.com/file.html?var1=...&var2=...';

Realisierbar wäre dies nämlich dann mit einem POST, anstatt einem GET:

<form id="updater" action="http://example-server-B.com/file.php" method="POST">
<input type="hidden" name="var1" value="...">
<input type="hidden" name="var2" value="...">
</form>

Mit document.getElementById('updater').submit(); könntest du dann immer wieder den iFrame aktualisieren und dort die POST Parameter auslesen. Die POST Daten sind zwar ebenfalls beschränkt, aber diese Beschränkungen liegen meist eher im Bereich mehrerer MB. Verwenden müsstest du dann allerdings zum Beispiel PHP, anstatt reines HTML + Javascript

Wenn du allerdings nicht möchtest, dass die iFrame-Seite ständig neu geladen wird, könnte auch die Verwendung der Textmarke Sinn machen, also der letzte Teil einer URL hinter der Raute:
http://example-server-B.com/file.html#var1-abc-var2-xyz
Somit könntest du Name-Werte-Paare einfügen, die du per Javascript ausliest und dann entsprechend splittest. Beachten muss man allerdings, welche Zeichen hier überhaupt erlaubt sind. Evtl ist die Konvertierung in Ascii-Werte oder base64 nötig. Soweit habe ich mich damit noch nicht befasst. Ob die maximale Länge hierbei aber nicht auch beschränkt ist, kann ich auch nicht sagen. Jedenfalls würden die ständigen HTTP-Requests wegfallen.

[Abraxax]

Ich kann nur mit JS arbeiten. Die iFrame-Source liegt auf einem Server der nur die reine Datei liefern kann. Also kein PHP.

POST wäre sicher eine Möglichkeit. Kann man überhaupt POST Daten mittels JS auslesen?

Zum Vorgehen ... Ich erstelle dynamisch ein iFrame und setze die Source dafür ebenfalls dynamisch. Der Inhalt wird einmal geladen.

@wasaga: Ein <script src ....> wäre eine gute Möglichkeit. Da aber die Source auch auf dem Server liegt, der nichts dynamisch in diese Dateien schreiben kann, bringt mir das nicht. Und die "master"-Datei referenzieren kann ich auch nicht, da ich deren Ort auch nicht (mehr) kenne. (innerhalb der nachgeladenen Dateien)

Ich muss alle Daten, welche ich innerhalb der nachgelandenen Datei(en) brauche "irgendwie" übergeben.

[reok]

Naja, wie du schon sagtest, durch die Cross-Site-Scripting Schutzmaßnahmen, sind genau solche Aktionen eigentlich nicht (mehr) möglich, ohne riesen Umwege. Brauchst du das Ganze denn nur für dich selber oder ist es eine Webseite, die für die Öffentlichkeit (bzw. auch andere Besucher) zugänglich sein soll?
Das Lockern von Sicherheitsrichtlinien im Browser oder der Einsatz von Greasemonkey oder anderen Tools würde nämlich evtl etwas helfen, falls du nur selber oder zumindest ein kleinerer Personenkreis damit arbeiten muss.
Sonst sehe ich da wenig Möglichkeiten. Per Javascript kann man jedenfalls nicht direkt auf POST-Daten zugreifen.

Im Prinzip kannst du natürlich auch den umgekehrten Weg gehen. Also du sendest die Daten nicht vom Parent an den Frame sondern forderst sie vom Frame beim Parent an. Hierzu muss aber dann zumindest der Parent Server PHP können. Dann könntest du im Frame eine Javascript-Datei einbinden, die auf dem Parent Server liegt und per PHP erstellt wird und somit dann die Daten hat, die du benötigst. Dynamischer wird das Ganze noch beim Zusammenspiel mit XMLHttpRequest. Ob das allerdings in irendeinerweise dienlich ist und nicht total den Rahmen sprengt, wage ich zu bezweifeln.

Mir persönlich fällt also sonst keine direkte Möglichkeit mehr ein. Aber warum willst du überhaupt so viele Daten an das Script übermitteln, das die Kapazität der GET Parameter nicht mehr ausreicht? Vielleicht sollte man hier ansetzen und versuchen die Daten einfach zu verringern, auszulagern oder geteilt zu übertragen?!

[wahsaga]

POST wäre sicher eine Möglichkeit. Kann man überhaupt POST Daten mittels JS auslesen?

Das hatte ich mehr zum Übergeben der Daten gemeint. Aber wenn du keinen Einfluss darauf hast, wie der Fremdserver Daten erstellt ...

Ein <script src ....> wäre eine gute Möglichkeit. Da aber die Source auch auf dem Server liegt, der nichts dynamisch in diese Dateien schreiben kann, bringt mir das nicht.

Wieso? Einbinden kannst du es doch auch unter deiner Domain - wo du dann auch Zugriff darauf hättest.

Ich muss alle Daten, welche ich innerhalb der nachgelandenen Datei(en) brauche "irgendwie" übergeben.

Was ist denn das für eine komische Bastel-Umgebung, in der man solche Klimmzüge machen muss?
Wer ist da wieder wo zu geizig, in eine vernünftige Schnittstelle zu investieren ...?

[Abraxax]

Wieso? Einbinden kannst du es doch auch unter deiner Domain - wo du dann auch Zugriff darauf hättest.

Das Problem ist, dass dies nicht meine Server sind und auch nicht unter einer unserer Domains laufen kann. Auch in dieser Version hätte ich das Problem der Datenübergabe. Dann evtl. kann ich PHP nutzen (POST 2 PHP), muss dann aber wieder vom externen Script auf meinen Server, um die Daten wieder zu holen.

Das ist dann wirklich krank. ;-)

Was ist denn das für eine komische Bastel-Umgebung, in der man solche Klimmzüge machen muss?

Das ist keine Bastel-Lösung. Das ist eine komplexe Webanwendung, welche ihre Daten aus Performance-Gründen in die Welt verteilt.

Wer ist da wieder wo zu geizig, in eine vernünftige Schnittstelle zu investieren ...?

Das hat nichts mit geizig zu tun. Ich habe nur keine Möglichkeit auf die Dateien auf den Akamai-Servern Einfluss zu nehmen. Denn dort liegt das nachzuladende File.

[wahsaga]

Ich habe nur keine Möglichkeit auf die Dateien auf den Akamai-Servern Einfluss zu nehmen. Denn dort liegt das nachzuladende File.

Na ja, dann lad' es nach, und gut ist.

Wenn das nicht geht - dann ist das für mich eine Bastel-Lösung.
Wenn Loadbalancing dazu führt, dass man clientseitig irgendwelche Klimmzüge machen muss, um an die Daten zu kommen ... dann läuft doch wohl irgendwas falsch.

[Abraxax]

Die benötigten Daten werden dynamisch generiert. Zu diesem Zeitpunkt sind die Dateien bereits verteilt.

Ich denke, dass wir hier zu keiner brauchbaren Lösung kommen.

Auf meiner Recherche habe ich noch DOM write() gefunden. Hiermit könnte ich den Inhalt des iFrames in eine vorhandene .html Datei schreiben. Damit könnte ich auf das iFrame verzichten und habe das Problem mit der Übergabe nicht mehr.

Was hälst du von dieser Art der Problembewältigung?
Krank oder akzeptabel?

[wahsaga]

Auf meiner Recherche habe ich noch DOM write() gefunden.

Du meinst document.write?

Hiermit könnte ich den Inhalt des iFrames in eine vorhandene .html Datei schreiben. Damit könnte ich auf das iFrame verzichten und habe das Problem mit der Übergabe nicht mehr.

Ich dachte, du hast keinen Zugriff auf das Script, das die Daten liefert?
Wenn du es so umschreiben kannst, dass es per document.write Inhalte ausgibt - dann solltest du doch auch alles andere denkbare mit ihm machen können?

Was hälst du von dieser Art der Problembewältigung?
Krank oder akzeptabel?

Ist der “old skool”-Weg, den JS-Counter, Banner-Services etc. seit Ewigkeiten nutzen - „funktioniert“ zumindest, ohne das man sich dabei um die SOP kümmern muss.
(Funktioniert nur in „echtem“ XHTML nicht mehr - ist aber egal, XHTML ist eh tot, und HTML5 unterstützt das weiterhin, wenn nicht als XML ausgeliefert.)

[Abraxax]

Du meinst document.write?

Nein.

Die Daten werden so oder so via document.write() geschrieben. Das Problem ist, dass die nachgeladenen Daten dies ebenfalls machen.

Die die Seite schon fertig geladen ist, habe ich ein Problem. Daher das iFrame. Damit habe ich das Problem der Variablenübergabe. Als Notlösung hatte ich DOM write() gefunden.

z.B. das hier ...

Auf das Hauptscript habe ich Zugriff. Aber nur bevor es verteilt wird. Während der Verteilung stehen aber erst verschiedene Daten fest, welche ich im Hauptscript mit speziellen Platzhaltern in mein Script packen kann. Ich kann dies jedoch nicht in den verteilten Daten, da diese 1:1 übergeben werden. Die spez. Vars werden dort leider nicht ersetzt.