Bisher wurde die lokale Sicherheit unter dem Gesichtspunkt einer einzelnen SWF-Datei erläutert: Keine individuelle SWF-Datei kann ohne Autorisierung des Benutzers sowohl die Berechtigung Lokal lesen als auch Im Netzwerk senden haben. Die Verbesserungen der lokalen Sicherheit in Flash Player 8 müssen jedoch auch Flash Player-Benutzer schützen, wenn mehrere SWF-Dateien miteinander kooperieren. Keine kooperierende Gruppe von SWF-Dateien kann kollektiv über die Berechtigungen Lokal lesen und Im Netzwerk senden verfügen.
Die Kooperation zwischen SWF-Dateien lässt sich mit zwei Schritten erreichen. Zunächst muss eine SWF-Datei die andere laden, normalerweise mit dem ActionScript-Befehl loadMovie. Zweitens müssen die beiden SWF-Dateien Informationen untereinander austauschen, und zwar mit ActionScript-Variablen, Methodenaufrufen, LocalConnection-Objekten und so weiter. Dieser Informationsaustausch wird auch als Cross-Scripting bezeichnet.
Zur Wahrung der lokalen Sicherheit verbietet Flash Player in manchen Fällen das SWF-Laden; in anderen Fällen ist das SWF-Laden möglich, aber das Cross-Scripting eingeschränkt.
SWF-Laden und Cross-Scripting sind immer zwischen SWF-Dateien zulässig, die sich in derselben Sandbox befinden. Beispielsweise kann jede SWF-Datei in der Sandbox Lokal mit Dateisystem jede andere SWF-Datei in derselben Sandbox laden und zum Cross-Scripting verwenden, und jede SWF-Datei in der Sandbox Lokal mit Netzwerk kann jede andere SWF-Datei in derselben Sandbox laden und zum Cross-Scripting verwenden. Einschränkungen gelten dann, wenn zwei SWF-Dateien aus unterschiedlichen Sandboxen versuchen, miteinander zu kooperieren.
Tabelle 1 zeigt die Einschränkungen in Bezug auf das Laden und Cross-Scripting zwischen Sandboxen. Die einzelnen Regeln werden im Anschluss aufgelistet. Jede Kooperation zwischen SWF-Dateien hat zwei Beteiligte. Die SWF-Datei, die die Kooperation einleitet (durch Aufruf von loadMovie oder Durchführung von Cross-Scripting), ist die aufrufende SWF, die andere die aufgerufene SWF. Die Bezeichnungen oberhalb der Tabelle beziehen sich auf die Sandbox der aufrufenden SWF, die Bezeichnungen links auf die Sandbox der aufgerufenen SWF.
| Sandbox der aufrufenden SWF | ||||
|---|---|---|---|---|
| Sandbox der aufgerufenen SWF | Lokal mit Dateisystem |
Lokal mit Netzwerk |
Lokal vertrauenswürdig |
Remote |
| Lokal mit Dateisystem |
Laden: zulässig Cross-Scripting: zulässig |
Laden: nicht zulässig | Laden: zulässig Cross-Scripting: zulässig |
Laden: nicht zulässig |
| Lokal mit Netzwerk |
Laden: nicht zulässig | Laden: zulässig Cross-Scripting: zulässig |
Laden: zulässig Cross-Scripting: zulässig |
Laden: nicht zulässig |
| Lokal vertrauenswürdig |
Laden: zulässig Cross-Scripting: erfordert Berechtigung |
Laden: zulässig Cross-Scripting: erfordert Berechtigung |
Laden: zulässig Cross-Scripting: zulässig |
Laden: nicht zulässig |
| Remote | Laden: nicht zulässig | Laden: zulässig Cross-Scripting: erfordert Berechtigung |
Laden: zulässig Cross-Scripting: zulässig |
Laden: zulässig Cross-Scripting: erfordert Berechtigung, wenn Domänen nicht übereinstimmen |
Die roten Zellen in Tabelle 1 beziehen sich auf Situationen, in denen bestimmte SWF-Dateien andere SWF-Dateien nicht laden können (mit loadMovie, loadMovieNum usw.):
Die beiden letzten Regeln lassen sich bei Bedarf relativ einfach umgehen, da eine SWF-Datei in der Sandbox Lokal mit Dateisystem problemlos in der Sandbox Lokal mit Netzwerk platziert werden kann und umgekehrt.
Die erste Regel, nach der Remote-SWFs keine lokalen SWFs laden können, ist jedoch unumstößlich. Im Gegensatz zu den meisten anderen Sicherheitsregeln in Flash Player kann diese Regel nicht umgangen werden. Diese Regel verhindert so genannte Zoneneskalationen. Eine Zoneneskalation tritt auf, wenn Inhalt in einer Zone mit weniger Berechtigungen (eine Remote-SWF) Inhalt in einer Zone aktiviert, die möglicherweise über mehr Berechtigungen verfügt (lokale SWFs). Wenn Sie eine eher unübliche Hybridanwendung (remote und lokal) verwalten, in der lokal installierter Inhalt gestartet wird, wenn Benutzer eine Webseite aufrufen, empfiehlt es sich, den Zugangspunkt zu ändern. Die Benutzer sollten in diesem Fall zunächst eine lokale SWF-Datei (oder einen lokalen Projektor, eine lokale ausführbare Datei usw.) anzeigen, über die dann der Online-Inhalt aktiviert wird.
In Flash Player gelten ähnliche Regeln für den Aufruf von getURL zum Laden von Browserseiten anstelle von SWFs:
Die gelben Zellen in Tabelle 1 zeigen Situationen, in denen eine SWF-Datei ein Cross-Scripting mit einer anderen SWF-Datei durchführen kann, vorausgesetzt, die aufgerufene SWF-Datei erteilt ausdrücklich eine entsprechende Berechtigung. Zu diesen Situationen gehören:
In Übereinstimmung mit dem Prinzip für globale Berechtigungen in Flash Player ist es in den ersten beiden Situationen erforderlich, dass die aufgerufene SWF-Datei den aufrufenden SWF-Dateien aus allen Sandboxen eine entsprechende Berechtigung erteilt. Dies erfordert den Aufruf von System.security.allowDomain("*") oder bei LocalConnection-Objekten die Angabe einer Prozedur LocalConnection.allowDomain, die den Wert true zurück gibt, wenn ein Domänenargument "localhost" angibt.
Flash Player ab Version 6 unterstützt permanente gemeinsame Objekte über die SharedObject-Klasse. Permanente gemeinsame Objekte speichern Daten auf den Computern der Benutzer. Normalerweise handelt es sich um lokale gemeinsame Objekte, die mit SharedObject.getLocal abgerufen werden. Es ist auch möglich, permanente gemeinsame Remote-Objekte zu erstellen. Dazu ist Flash Media Server* (früher Flash Communication Server) erforderlich. Gemeinsame Remote-Objekte werden in der Dokumentation dieses Produkts beschrieben.
Jede Remote-Sandbox verfügt über einen zugehörigen Speicher mit permanenten gemeinsamen Objekten. Wenn beispielsweise eine SWF-Datei aus domain1.com ein permanentes gemeinsames Objekt liest oder schreibt, liest oder schreibt Flash Player dieses Objekt im Objektspeicher von domain1.com. Für eine SWF-Datei aus domain2.com verwendet Flash Player analog den Objektspeicher von domain2.com. Um Namenskonflikte zu vermeiden, werden permanente gemeinsame Objekte zusätzlich durch einen Pfad identifiziert. Standardmäßig ist dies der vollständige Pfad in der URL der erstellenden SWF-Datei. Der Pfad kann jedoch mit dem Parameter localPath in SharedObject.getLocal verkürzt werden, wodurch andere SWF-Dateien in derselben Domäne auf ein erstelltes gemeinsames Objekt zugreifen können.
In Flash Player 7 und früheren Versionen wurde für alle lokalen SWF-Dateien derselbe permanente gemeinsame Objektspeicher verwendet. Ab Flash Player 8 sind zwei lokale gemeinsame Objektspeicher vorhanden. In Übereinstimmung mit einem schon vorhandenen Muster gewährleistet Flash Player, dass SWF-Dateien in der Sandbox Lokal mit Dateisystem nicht mit SWF-Dateien in der Sandbox Lokal mit Netzwerk kommunizieren können. In diesem Fall wird dies erreicht, indem jeder der beiden lokalen Sandboxen ein separater gemeinsamer Objektspeicher zugewiesen wird.
Flash Player weist lokale vertrauenswürdige SWF-Dateien demselben gemeinsamen Objektspeicher zu wie SWF-Dateien in der Sandbox Lokal mit Dateisystem. Dies erleichtert den Übergang vom Standardstatus Lokal mit Dateisystem zum lokalen vertrauenswürdigen Status, den Endbenutzer möglicherweise zuweisen, um vorhandenen lokalen Inhalt zu reparieren, der nicht mehr wie beabsichtigt funktioniert. Wenn SWF-Dateien diesen Übergang vornehmen, behalten sie die gemeinsamen Objekte bei, die sie erstellt haben.
