wie Domainübergreifend Daten austauschen ?

[Hans]

Ich möchte eine Seite der Domain xxx als Iframe auf der Domain yyy einbauen. Damit es keinen Scrollbalken gibt möchte ich dass ein Script der eingebauten Seite (domain xxx) auf das parent-frame (domain yyy) zugreift und dort die frame-height richtig setzt.

Im Netz find ich nur die Behauptung dass es bei Javascript eine Same-Domain-Policy gibt. Aber wenn ich zB eine Google-Maps auf meine Homepage einbinde, dann lädet deren Javascriptteil ständig Daten von Google nach und modifiziert entsprechend den Inhalt einer <div id="map">, die aber auf meiner Domain liegt.

Weis wer wie die diese Same-Domain-Policy umgehen ?

Grüsse

[Struppi]

Im Netz find ich nur die Behauptung dass es bei Javascript eine Same-Domain-Policy gibt. Aber wenn ich zB eine Google-Maps auf meine Homepage einbinde, dann lädet deren Javascriptteil ständig Daten von Google nach und modifiziert entsprechend den Inhalt einer <div id="map">, die aber auf meiner Domain liegt.

Das ist nicht die SOP. Das betrifft das Dokument. JS darf nicht auf ein anderes Dokument zugreifen, von dem es selber eingebunden wurde.

Weis wer wie die diese Same-Domain-Policy umgehen ?

Gar nicht.

Struppi.

[suit]

Weis wer wie die diese Same-Domain-Policy umgehen ?

Gar nicht.

Sicher geht das: mit einem "Proxy" z.B. bzw. einem primitiven Script, welches einfach nur Requests weiterschleift.

Btw: wie siehts mit document.domain aus?

[Struppi]

Weis wer wie die diese Same-Domain-Policy umgehen ?

Gar nicht.

Sicher geht das: mit einem "Proxy" z.B. bzw. einem primitiven Script, welches einfach nur Requests weiterschleift.

Da das Thema Javascript war, ging ich von einer JS Frage aus. Das verschiedene Domains mit einander kommunizieren könne ist klar, das ist das Internet.

Btw: wie siehts mit document.domain aus?

Wie meinst du das?

Struppi.

[Tom]

Hello,

Weis wer wie die diese Same-Domain-Policy umgehen ?

Gar nicht.

Sicher geht das: mit einem "Proxy" z.B. bzw. einem primitiven Script, welches einfach nur Requests weiterschleift.

... und alle Referenezn(Links) umschreibt.

Sooo simpel ist das auch wieder nicht.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Struppi]

Btw: wie siehts mit document.domain aus?

Ach du meinst das man mit Subdomains diese Einschränkung umgehen kann. Danach hatte Hans nicht gefragt, zumindest klingt seine Formulierung nicht so.

Struppi.

[suit]

Ach du meinst das man mit Subdomains diese Einschränkung umgehen kann. Danach hatte Hans nicht gefragt, zumindest klingt seine Formulierung nicht so.

Richtig - ich lese das aber auch eher so, also ob es um gänzlich verschiede Domains geht.

[hans]

Sicher geht das: mit einem "Proxy" z.B. bzw. einem primitiven Script, welches einfach nur Requests weiterschleift.

mit einem php proxy hab ich schon probiert. die seitenladezeit war dann auf einmal bei einer sekunde.

hab auch probiert ueber die url daten auszutauschen. also in domain xxx ist ein 2tes iframe wo alle 500 ms ein php script der domain yyy aufgerufen wird. dieses script macht dann immer einen header-redirect auf ein html/js-script der domain xxx und übergibt per GET die parameter an das JS der domain xxx. funktioniert, leider blinkt alle 500ms der betreffende tab im firefox nerfig auf.

wie bringt zB google-ads es zusammen fremdlinks auf meiner seite einzubaun und sich die daten aber von deren domain zu holen ?

[suit]

wie bringt zB google-ads es zusammen fremdlinks auf meiner seite einzubaun und sich die daten aber von deren domain zu holen ?

Tut es doch überhaupt nicht. Es holt lediglich Zeug von Google.

[hans]

wie bringt zB google-ads es zusammen fremdlinks auf meiner seite einzubaun und sich die daten aber von deren domain zu holen ?

Tut es doch überhaupt nicht. Es holt lediglich Zeug von Google.

naja, google is ja deren domain :)

wenn ich mir mit firebug so ein google adsense feld anschaue, dann sind all die werbelinks direkt auf der betreffenden domain in div feldern eingebaut (kein iframe!). das betreffende script von google (was diese links erzeugt) muss die daten aber doch irgendwie von der google domain abfragen. und um adsense zu verwenden muss man keinen php proxy raufladen. also is das doch eine umgehung des SOP, oder hab ich da einen gedankenfehler ?

[suit]

wenn ich mir mit firebug so ein google adsense feld anschaue, dann sind all die werbelinks direkt auf der betreffenden domain in div feldern eingebaut (kein iframe!). das betreffende script von google (was diese links erzeugt) muss die daten aber doch irgendwie von der google domain abfragen. und um adsense zu verwenden muss man keinen php proxy raufladen. also is das doch eine umgehung des SOP, oder hab ich da einen gedankenfehler ?

Die erzeugten Links haben nichts damit zu tun woher JavaScript die Daten bekommt :)

[ChrisB]

Hi,

wenn ich mir mit firebug so ein google adsense feld anschaue, dann sind all die werbelinks direkt auf der betreffenden domain in div feldern eingebaut (kein iframe!). das betreffende script von google (was diese links erzeugt) muss die daten aber doch irgendwie von der google domain abfragen. und um adsense zu verwenden muss man keinen php proxy raufladen. also is das doch eine umgehung des SOP, oder hab ich da einen gedankenfehler ?

Ja, hast du.
Das Script selber fordert keine weiteren Daten von irgendwo an.

MfG ChrisB

[Don P]

Hallo,

Das Script selber fordert keine weiteren Daten von irgendwo an.

Bist du sicher?
Gemeint ist doch anscheinend, dass wenn man irgend eine Seite ansurft, das geladene Dokument auch Daten von einer anderen Domain holen kann, z.B. die aktuelle AdSense-Werbung von Google.

Das ist genau die Sicherheitslücke, die ich an anderer Stelle mal erwähnt habe, falls du dich erinnerst. Die SOP greift hier nämlich nicht, weil die Werbeindustrie das nicht haben will.

Gruß, Don P

[ChrisB]

Hi,

Das Script selber fordert keine weiteren Daten von irgendwo an.

Bist du sicher?
Gemeint ist doch anscheinend, dass wenn man irgend eine Seite ansurft, das geladene Dokument auch Daten von einer anderen Domain holen kann, z.B. die aktuelle AdSense-Werbung von Google.

Da wird ein Script eingebunden, ja.
Das Script selber lädt aber keine Daten nach.

Das ist genau die Sicherheitslücke, die ich an anderer Stelle mal erwähnt habe, falls du dich erinnerst. Die SOP greift hier nämlich nicht, weil die Werbeindustrie das nicht haben will.

Dass das keine Sicherheitslücke ist, wurde dir da IIRC auch schon gesagt.

MfG ChrisB

[Don P]

Hallo,

Da wird ein Script eingebunden, ja.
Das Script selber lädt aber keine Daten nach.

LOL - Im eingebundenen Script *sind* die nachgeladenen Daten, und es kann jederzeit weitere einbinden mit weiteren Daten aus jeder Ecke der Welt, wenn es will, bzw. wenn sein Programmierer es will. Wenn das keine Sicherheitslücke ist...

Aber ein aufpoppender Filedialog ist ja vieeel schlimmer, gelle...

Gruß, Don P

[ChrisB]

Hi,

LOL - Im eingebundenen Script *sind* die nachgeladenen Daten, und es kann jederzeit weitere einbinden mit weiteren Daten aus jeder Ecke der Welt, wenn es will, bzw. wenn sein Programmierer es will. Wenn das keine Sicherheitslücke ist...

Das wäre eine, die du dir selbst einhandelst, wenn du als Ersteller der Seite dem Anbieter des ersten, externen Scriptes vertraust.

Das zu unterbinden, ist nicht Aufgabe der SOP.

Aufgabe der SOP ist, zu verhindern, dass ich deine Seite bspw. in einem Frame anzeige, und dann von einem anderen Frame aus die Logindaten, die der Nutzer in dein Loginformular eingibt, abgreife.

Ob und in wie fern es sinnvoll ist, dass die SOP auch bspw. AJAX-Requests an andere Domains einschränkt/unterbindet, könnte man diskutieren. Man mag vielleicht der Ansicht sein, dass sie diesbezüglich zu pauschal implementiert ist.

MfG ChrisB

[Pragma]

Aber ein aufpoppender Filedialog ist ja vieeel schlimmer, gelle...

Äpfel? Birnen?

[Don P]

Hallo,

Aber ein aufpoppender Filedialog ist ja vieeel schlimmer, gelle...

Äpfel? Birnen?

Nö, das passt schon.
Es ging damals genau um diese Punkte. Der Thread ist schon irgendwo im Archiv. Sorry, wenn jetzt nicht jeder mitkommt. Wir sind auch gleich fertig.

Gruß, Don P

[Struppi]

LOL - Im eingebundenen Script *sind* die nachgeladenen Daten, und es kann jederzeit weitere einbinden mit weiteren Daten aus jeder Ecke der Welt, wenn es will, bzw. wenn sein Programmierer es will. Wenn das keine Sicherheitslücke ist...

Natürlich ist das eine und zwar eine sehr grosse und in den letzten Jahren oft verwendete und nennt sich XSS

Aber ein aufpoppender Filedialog ist ja vieeel schlimmer, gelle...

Nein, die Lücke ist eher kleiner. Sie wurde meines Wissens nur für kleinere Spielereien ausgenutzt, die nie jemanden wirklich geschadet haben.

Struppi.

[Don P]

Hallo,

Das Script selber lädt aber keine Daten nach.

Und woher weiß ich das? Doch nicht etwa weil du oder der Scripter es mir versichert? ;)

Gruß, Don P

[ChrisB]

Hi,

Das Script selber lädt aber keine Daten nach.

Und woher weiß ich das? Doch nicht etwa weil du oder der Scripter es mir versichert? ;)

Es geht nicht um die Sicht des Benutzers, sondern um die des Erstellers der Seite.

MfG ChrisB

[Don P]

Hallo,

Das Script selber lädt aber keine Daten nach.

Und woher weiß ich das? Doch nicht etwa weil du oder der Scripter es mir versichert? ;)

Es geht nicht um die Sicht des Benutzers, sondern um die des Erstellers der Seite.

Wie? Bei der Sicherheit geht es nicht um die Sicht des Benutzers?

Wenn ein externes Script mit den gleichen Rechten arbeiten kann wie eines von meiner Seite, ohne dass der Benutzer irgend etwas davon mitbekommt, wenn es auf die Cookies Zugriff hat, beliebeige Daten vom DOM lesen (auch von Formularen) und irgedwohin verschicken kann, das DOM umbauen kann, dieselben Rechte auch anderen Scripts von irgendwoher gewähren kann...

Wohlgemerkt: Der Butzer merkt davon *nichts*. Er vertraut vielleicht mir, aber vertraut er auch den anderen, die da noch mitmischen, wenn ich ihm gar nichts davon sage und es evtl. selber gar nicht weiß, weil die gestern noch so lieb waren wie Google und morgen vielleicht...

Wenn ich aber ein File-Upload-Feld in meine Seite baue, dann rufst du schon "Sicherheitsproblem!" und "woher weiß ich denn, dass da nicht etwas heimlich hochgeladen wird?" usw.

Sorry, das kann ich nicht ernst nehmen.

Gruß, Don P

[ChrisB]

Hi,

Es geht nicht um die Sicht des Benutzers, sondern um die des Erstellers der Seite.

Wie? Bei der Sicherheit geht es nicht um die Sicht des Benutzers?

Ich bezog mich mit der Aussage auf die SOP.

Wenn ein externes Script mit den gleichen Rechten arbeiten kann wie eines von meiner Seite, ohne dass der Benutzer irgend etwas davon mitbekommt, wenn es auf die Cookies Zugriff hat, beliebeige Daten vom DOM lesen (auch von Formularen) und irgedwohin verschicken kann, das DOM umbauen kann, dieselben Rechte auch anderen Scripts von irgendwoher gewähren kann...

Ob meine Kreditkartendaten von einem Schurken aus Russland, oder von Don P missbraucht werden, ist für mich als Nutzer vollkommen ohne Belang.

Du kannst sie auch offline weitergeben, ohne dass dafür irgendwelche irgendwo eingebundenen Scripte nötig wären.

Wohlgemerkt: Der Butzer merkt davon *nichts*. Er vertraut vielleicht mir, aber vertraut er auch den anderen, die da noch mitmischen, wenn ich ihm gar nichts davon sage und es evtl. selber gar nicht weiß, weil die gestern noch so lieb waren wie Google und morgen vielleicht...

Du siehst, es läuft letztendlich darauf hinaus, wie vertrauenswürdig du als Seitenbetreiber für mich bist.

Ein externes Script befindet sich nur dann in deiner Seite, wenn du es bewusst dort eingebunden hast. (Sofern wir mal davon ausgehen, dass deine Seite keine XSS-Lücken aufweist.)

Wenn ich aber ein File-Upload-Feld in meine Seite baue, dann rufst du schon "Sicherheitsproblem!" und "woher weiß ich denn, dass da nicht etwas heimlich hochgeladen wird?" usw.

Ein Upload von Dateien von meinem Rechner auf deinen Server setzt aus gutem Grund mein explizites Einverständnis voraus.

Sorry, das kann ich nicht ernst nehmen.

Das Problem habe ich mit dir auch, wenn du dich so hartnäckig weigerst zu erkennen, dass du verschiedene Sachverhalte in einen Topf schmeisst.

MfG ChrisB

[hans]

Wenn ein externes Script mit den gleichen Rechten arbeiten kann wie eines von meiner Seite, ohne dass der Benutzer irgend etwas davon mitbekommt, wenn es auf die Cookies Zugriff hat, beliebeige Daten vom DOM lesen (auch von Formularen) und irgedwohin verschicken kann, das DOM umbauen kann, dieselben Rechte auch anderen Scripts von irgendwoher gewähren kann...

ach so machen die das, einbau von externen scripts die on the fly erzeugt werden. das externe js-script ist dann quasi ein php script was den js-code live erstellt und gleich die nachzuladenden daten in den code reinschreibt.

danke für den tip, so kann ich mein problem lösen.

[Struppi]

danke für den tip, so kann ich mein problem lösen.

Das hab ich dir von Anfang an gesagt. Du darfst Skripte in deine Seite einbinden, egal von welcher Domain sie kommen und diese haben zugriff auf deine komplette Seite. Das hat aber nichts mit der SOP zu tun.

Struppi.

[hans]

Das hab ich dir von Anfang an gesagt. Du darfst Skripte in deine Seite einbinden, egal von welcher Domain sie kommen und diese haben zugriff auf deine komplette Seite. Das hat aber nichts mit der SOP zu tun.

danke dir auch. habs übrigends schon fertig.

die externen js-scripts tu ich über .htaccess auf ein php script umgelenken, was aus der url die benötigte abfrage rausholt und als ausgabe ein javascript erzeugt was die angeforderten daten in variablen übergeben bekommt.

und ja: wenn DAS keine sicherheitslücke ist.. (ich kann ja jederzeit auch schadcode liefern wenn ich will.)

[Struppi]

Sorry, das kann ich nicht ernst nehmen.

Dann muss man sagen, dass du nicht wirklich nachgedacht hast, wo hier das Problem liegt und wer die Verantwortung für was trägt.

Es ist genauso wie du es sagst. Das Einbinden von einer fremden Domain wird ausgenutzt, das Stichwort XSS hatte ich dir ja schon genannt. Von daher wäre es sinnvoll zu überlegen diese Sache einzuschränken, dann würden aber vermutlich Leute wie du aufschreien, wie bei der Einschränkung des Fileupload Feldes.

Wobei aber die Verantwortlichkeit für den Bug jeweils woanders liegt.

Ein XSS Exploit ist ein Mangel in der Serversoftware, die Verantwortung liegt hier also in der Hand des Entwicklers. Der Fehler ist nicht im Browser, da es von vielen Entwicklern gewünscht wird, JS von einer fremden Domain einzubinden zu dürfen, wird diese Sache nicht eingeschränkt. Bei dem Fileupload ist genau umgekehrt, wenn diese funktionalität ausgenutzt werden könnte, wäre es ein Fehler im Browser und er würde zu recht als Mangelhaft bezeichnet werden.

Und genau das ist ja jahrelang passiert, der IE hatte genau unter solchen mängeln zu leiden und jede Woche tauchten neue Lücken auf, die genau solche Sachen ausnutzten um Schaden anzurichten. Das ist der Grund warum Firefox relativ schnell so erfolgreich werden konnte. Weil bei M$ Leute saßen, die so argumentierten wie du.

Struppi.

[Don P]

Hallo,

Dann muss man sagen, dass du nicht wirklich nachgedacht hast, wo hier das Problem liegt und wer die Verantwortung für was trägt.

Doch, habe ich.

Es ist genauso wie du es sagst. Das Einbinden von einer fremden Domain wird ausgenutzt, das Stichwort XSS hatte ich dir ja schon genannt. Von daher wäre es sinnvoll zu überlegen diese Sache einzuschränken, dann würden aber vermutlich Leute wie du aufschreien, wie bei der Einschränkung des Fileupload Feldes.

*Ich* würde nicht aufschreien.

Wobei aber die Verantwortlichkeit für den Bug jeweils woanders liegt.

Ein XSS Exploit ist ein Mangel in der Serversoftware, die Verantwortung liegt hier also in der Hand des Entwicklers. Der Fehler ist nicht im Browser, da es von vielen Entwicklern gewünscht wird, JS von einer fremden Domain einzubinden zu dürfen, wird diese Sache nicht eingeschränkt.

Verstehe: Weil es von Entwicklern gewünscht wird, wird also zugelassen, dass die z.B. auch XSS-Exploits programmieren können, von denen der Benutzer nichts merkt. Und das ist natürlich kein Fehler im Browser.
Wenn Google morgen beschließt, die Leute noch mehr auszuspionieren als sie es m.M.n. ohnehin schon tun, dann fühlt sich kein Browserhersteller zuständig, einen Schutz dagegen einzubauen. Es gibt ja kaum noch Seiten im Netz, wo solche externen Scripts nicht eingebunden sind.

Bei dem Fileupload ist genau umgekehrt, wenn diese funktionalität ausgenutzt werden könnte, wäre es ein Fehler im Browser und er würde zu recht als Mangelhaft bezeichnet werden.

Es ging ja nie darum, dass das ausnutzbar werden soll, sondern nur darum, das viele Entwickler wie z.B. ich gern mehr Formatierungsmöglichkeiten für solche Felder hätten und vielleicht ein Filedialog auch mal mer JS geöffnet werden kann, so dass der Benutzer (nach seiner Zustimmung!) eine Datei aus seinem System zum Upload oder einen Ordner zum Download wählen kann.

Verstehe also: Wenn man dem Benutzer eine Möglichkeit geben will einzugreifen, dann muss man ihn vor sich selbst schützen, weil er u.U. zu blöd ist, etwas zu entscheiden. Dafür ist der Browser dann wieder zuständig.

Was für eine Logik ist das, und was für ein Verständnis von Sicherheit bzw. von Privatsphäre?

Gruß, Don P

[ChrisB]

Hi,

Dann muss man sagen, dass du nicht wirklich nachgedacht hast, wo hier das Problem liegt und wer die Verantwortung für was trägt.

Doch, habe ich.

Manche Leute denken, und es kommt doch nix dabei rum ...

Verstehe: Weil es von Entwicklern gewünscht wird, wird also zugelassen, dass die z.B. auch XSS-Exploits programmieren können, von denen der Benutzer nichts merkt.

XSS wird gemeinhin dann als Lücke betrachtet, wenn Code ausgeführt wird, ohne dass der *Seitenbetreiber* dies beabsichtigt hat.

Noch mal - ob du ein Script auf deiner Seite einbindest, welches meine Kreditkartendaten nach Moskau übermittelt, oder ob du, ganz ohne XSS, dort anrufst und sie selber durchgibst, macht für mich als Nutzer deiner Seite keinen Unterschied.

Es kommt allein darauf an, wie vertrauenswürdig du als Seitenbetreiber mir erscheinst.

Es ging ja nie darum, dass das ausnutzbar werden soll, sondern nur darum, das viele Entwickler wie z.B. ich gern mehr Formatierungsmöglichkeiten für solche Felder hätten und vielleicht ein Filedialog auch mal mer JS geöffnet werden kann, so dass der Benutzer (nach seiner Zustimmung!) eine Datei aus seinem System zum Upload oder einen Ordner zum Download wählen kann.

Siehst du, hier vermischst du schon wieder zwei vollkommen gegensätzliche Dinge.

Wenn du mir weiss machen willst, dass ich nur deshalb eine Datei über den Button auswählen soll, weil du daraus den Order ermitteln willst, in dem ein Download gespeichert werden soll - dann braucht das nicht den Tatsachen zu entsprechen, und das Formular kann doch im nu abgesendet sein.

Ergo: Upload-Felder sind nur für Uploads da, und nicht für irgendwas anderes zu missbrauchen. Ein Browser, der dir weitergehende Kontrolle über Button und Dialog erlaubt, ist ein Sicherheitsrisiko für mich als Nutzer.

Verstehe also: Wenn man dem Benutzer eine Möglichkeit geben will einzugreifen, dann muss man ihn vor sich selbst schützen, weil er u.U. zu blöd ist, etwas zu entscheiden. Dafür ist der Browser dann wieder zuständig.

Ja, ist er.

Was für eine Logik ist das, und was für ein Verständnis von Sicherheit bzw. von Privatsphäre?

Eins, zu dem dir erstaunlicherweise immer noch die Einsicht fehlt.
(Obwohl ich langsam glaube, dass du deine Meinung nur aus Sturheit beibehältst.)

MfG ChrisB

[Don P]

Hallo,

XSS wird gemeinhin dann als Lücke betrachtet, wenn Code ausgeführt wird, ohne dass der *Seitenbetreiber* dies beabsichtigt hat.

Noch mal - ob du ein Script auf deiner Seite einbindest, welches meine Kreditkartendaten nach Moskau übermittelt, oder ob du, ganz ohne XSS, dort anrufst und sie selber durchgibst, macht für mich als Nutzer deiner Seite keinen Unterschied.

Es kommt allein darauf an, wie vertrauenswürdig du als Seitenbetreiber mir erscheinst.

Wenn ein Seitenbetreiber absichtlich fremden Code einbindet, dann kann er noch so vertrauenswürdig sein für den Nutzer, der fremde Code muss es deswegen noch lange nicht sein. Wenn ich Code von dir einbinde, weil du mir vielleicht vertrauenswürdig erscheinst, dann kann sich dein Code morgen ändern (oder der, den dein Code wiederum zusätzlich einbindet), ohne dass ich das als Seitenbetreiber überhaupt merke und der Nutzer meiner Seiten erst recht nicht. Fremden Code einzubinden ist deshalb per se ein Sicherheitsrisiko, und eine diesbezügliche SOP würde dagegen helfen und wäre m.M.n. auch sinnvoll.

Das Risiko besteht hier wohlgemerkt  *trotz Vertrauenswürdigkeit* und Rechtschaffenheit des Seitenbetreibers und ist daher schwerwiegender einzustufen als eins, das durch ein Upload-Feld entsteht, weil da der Nutzer ja immerhin noch zweimal die Möglichkeit hat, den Zugriff zu verweigern: 1. indem er schon bei der Sicherheitswarnung ablehnt, so dass der File-Dialog gar nicht erst erscheint und 2. indem er dann doch keinen Ordner oder keine Datei im Dialog wählt, falls er dann beschließt, mir nicht zu vertrauen.

Was für eine Logik ist das, und was für ein Verständnis von Sicherheit bzw. von Privatsphäre?

Eins, zu dem dir erstaunlicherweise immer noch die Einsicht fehlt.
(Obwohl ich langsam glaube, dass du deine Meinung nur aus Sturheit beibehältst.)

Sicher nicht aus Sturheit. Vielleicht bin ich ja wirklich zu blöd die Zusammenhänge richtig zu sehen. Vielleicht bist es aber auch du, der es nicht sieht oder einfach stur ist...

Gruß, Don P

[Struppi]

wie bringt zB google-ads es zusammen fremdlinks auf meiner seite einzubaun und sich die daten aber von deren domain zu holen ?

Weil du sie einbindest.

Struppi.

[Cheatah]

Hi,

Sicher geht das: mit einem "Proxy" z.B. bzw. einem primitiven Script, welches einfach nur Requests weiterschleift.

dass der Server keiner Same Origin Policy unterliegt war nicht gefragt. JavaScript kann weiterhin nur und ausschließlich mit dem selben Server kommunizieren - unabhängig davon, was der dann macht.

Cheatah