Cross-Side-Access

Alle Beispiele hier, die sich um einen dritten Server drehen, von dem aus eine Kommunikation zurück erfolgen soll, müssen natürlich einen solchen dritten Server an den Haaren herbeiziehen, wobei ich selbst erstmal nur einen einzelnen Server ("harryboeck.dyndns.org") betreibe, auf dem diese Beispiele abgelegt sind. Jener dritte Server wird hier erstmal dadurch an den Haaren herbeigezogen, daß ich den "localhost" eingetragen habe. Das reicht aus, um einen Verstoß gegen die "Same-Origin-Policy" triggern zu lassen.

Besucher dieser Seite haben dabei natürlich das Problem, daß diese Experimente erstmal für sie nicht funktionieren. Das ist der Natur der Sache geschuldet: Hier sollen Beziehungen zwischen DREI Parteien (Client + Server + Dritter) untersucht werden, wobei der Browser des Besuchers erstmal den "Client" darstellt und der Server, wo diese Experimente abgelegt sind, den "Server". Der Dritte darf weder der erste noch der zweite sein. Logisch, gelle?!

Wer die Experimente also selbst funktionsfähig nachvollziehen will, muß sich zuerst einen solchen "Dritten" Rechner selbst auf die Beine stellen und die Dateien, die auf diesem liegen sollen, auf diesen kopieren. Damit die Experimente hier sofort (ohne weitere Anpassung) ausführbar werden, muß dieser "Dritte" im Bunde der eigene "localhost" sein (siehe XAMPP falls es da Fragen geben sollte). Man muß also die Dateien des "Dritten" auf den Webspace seines eigenen "localhost" ablegen, gelle?! Unter demselben Verzeichnispfad, der hier benutzt wird ("/Experimente/js/cross-side-access/"), gelle?!

Das sind im einzelnen:
Dokument laden (bzw. Daten dorthin senden) vom Server, von dem die umgebende HTML-Datei kam (test.txt):
-> geht erstmal (soll ja auch so sein, nur zur Kontrolle)...

Dokument laden (bzw. Daten dorthin senden) von einem anderen als dem Server, von dem die umgebende HTML-Datei kam (http://noscript.net/abe/):
-> Geht erstmal nicht. Korrekt.
Wobei man sich nach der Fehlermeldung beim Firefox die Kugel geben kann.

Ein Script, das von einem dritten Server in eine Seite eingebunden wird, kann aus dieser einbindenden Seite heraus auf jenen dritten Server, von dem es stammt, nicht zugreifen... ("test.js" über localhost -> versucht, in die Box hier den Inhalt der vom localhost nachgeladenen "test.txt" zu schreiben):

IFrames allerdings dürfen alles von überall laden, wenn sie nicht durch extra Werkzeuge aufgehalten werden:
-> Ohne Noscript anstandslos und ohne Nachfrage geladen.

Aus einem IFrame heraus geht der Zugriff sehr wohl zu dessen Ursprungsserver:
-> Ohne Noscript anstandslos und ohne Nachfrage geladen und ausgeführt.

Allerdings geht kein Zugriff aus dem IFrame heraus auf das umgebende Fenster oder auch aus dem Rahmenfenster in den IFrame hinein (auch nicht, nachdem NoScript zum Ausführen des IFrames gezwungen wurde)...

AAAABER: Übertragung von Nachrichten mittels Austausch der IFrame-Source: => funktioniert. Wobei man dasselbe auch durch Eröffnen eines neuen Fensters erreichen könnte, was nur eventuell optisch auffallen würde - besonders, wenn der Browser-Benutzer in seinen Javascript-Einstellungen Restriktionen für die per Javascript erlaubten Manipulationen an Fenstereigenschaften eingestellt hätte. Das Austauschen der Sourcen von kleinen, unsichtbar geschalteten Elementen auf der Seite (IFrame oder img oder script oder irgendwelchen sonstigen Elementen, die das Laden von Inhalten aus dem Internet ermöglichen) geht da deutlich "sicherer"...
Hier wird also einfach die Quelle einer Ressource ausgetauscht und dadurch Nachrichten aus einer Seite heraus in die Welt geschickt...

Wobei: Das Zurückschicken von Nachrichten klappt auf diese Weise noch immer nicht. Ein Angreifer muß seinen Code in diesem Fall (IFrame) also immer noch in der anzugreifenden Seite (von der aus Daten abgefangen werden sollen) platzieren...

"Hübsch" gemacht sieht das für einen bösen Buben so aus:
var sendmsg = function(dst,msg)
{
	sender.src = dst+"?msg="+encodeURIComponent(msg);
}

Übrigens geht das auch für Images und Scripts und alle eventuell sonst noch existierenden HTML-Elemente, die ein src-Attribut haben.

Noch ein AAAABER: Mit Fenstern sieht das schon wieder unter Umständen anders aus: Siehe Firefox 16 Crossdomain Exploit!

Zusammenfassung:

OK: Soweit sieht es mit der Script-Politik erstmal recht anständig aus: Gegen den Austausch des src-Attributes von Frames/Images/Scripts und dergleichen hilft allerdings keine Script-Politik, denn wenn DAS unterdrückt werden würde, wären Frames generell als DOM-Elemente vom Scripting ausgenommen. Wobei: Das wäre nicht undenkbar. Ist aber derzeit nicht so gewollt und nicht so implementiert. Ergo hat die ganze Politik der Zugriffsbeschränkung über Origin-Grenzen hinweg nur Wirkung gegen Flüchtigkeitsfehler von "lieben Buben", nicht aber gegen gewollten Mißbrauch durch "böse Buben": Ein Script kann JEDE BELIEBIGE URL mit jedem beliebigen Inhalt als Parameter aufrufen und damit die Same-Origin-Sicherungen trivial umgehen. Es kann auch dynamisch und unsichtbar Frames erzeugen oder in vorhandenen unsichbaren die src austauschen, so daß der Browsernutzer nichts von alledem mitbekommt.

Ergo: Die ganze "Same-Origin"-Politik ist für den Arsch, sobald man zuläßt, daß Scripte aus der ganzen Welt ohne jede Kontrolle in jedem beliebigen Kontext ausgeführt werden dürfen. Denn jedes dieser Scripte kann sehr wohl Nachrichten aus seinem Fenster heraus an jeden beliebigen Punkt der Welt schicken.

Schon bei den praktisch lückenlos gestreuten Ad-Servern hört jede Kontrollierbarkeit auf, weil das schlicht von den Ad-Server-Betreibern nicht geleistet werden kann. In praktisch allen gängigen Foren alias Communities (in letzteren ganz besonders) setzt sich das fort durch ununterbrochen und per Weiterentwicklung immer aufs neue kreierte herumgeisternde Programmierfehler.
Von der nicht zu leistenden Kontrollierbarkeit abgesehen stellen Scripte wie zum Beispiel von Trackern an sich einen Verstoß gegen jeden Anstand alias Zurückhaltung dar. Tracker-Scripte zuzulassen bedeutet faktisch nakt im Internet unterwegs zu sein.

Fazit: Behaltet Javascript abgeschaltet!