Die folgenden Szenarios sollen die Auswirkungen der neuen Regeln für die lokale Sicherheit in Flash Player 8 veranschaulichen.
Die Regeln für die lokale Sicherheit in Flash Player 8 sollen Endbenutzer schützen. Aus der Position der Endbenutzer sind lokale SWF-Dateien in der Regel endgültiger Inhalt, der vom Internet heruntergeladen oder als Teil einer Anwendung installiert wurde. Dagegen sind lokale SWF-Dateien für Flash-Autoren häufig temporäre Kopien von Inhalt, der sich noch in der Entwicklung befindet und später auf einem HTTP-Server bereitgestellt werden soll. In manchen Fällen können die Sicherheitseinschränkungen verhindern, dass der Inhalt wie beabsichtigt funktioniert, weil Sie die SWF-Dateien in der Vorschau anzeigen, während es sich noch um lokale Dateien handelt.
Im Folgenden werden drei Testverfahren für Flash-Inhalt in der Entwicklungsphase aufgelistet, und zwar nach zunehmender Komplexität:
Um beim Testen mit der Vorschau im Browser unerwünschte Sicherheitseinschränkungen zu vermeiden, müsste Flash Player im Idealfall zwischen Flash-Inhalt in der Entwicklungsphase und nicht vertrauenswürdigen, aus dem Internet heruntergeladenen SWF-Dateien unterscheiden können. Dies ist jedoch in Flash Player nicht auf zuverlässige, automatisierte Weise möglich.
Stattdessen empfiehlt es sich möglicherweise, Flash Player so zu konfigurieren, dass alle SWF-Dateien in bestimmten Verzeichnissen des lokalen Dateisystems als vertrauenswürdig betrachtet werden. Wenn Sie beispielsweise alle Flash-Dateien unter C:\FlashSites speichern, können Sie im Einstellungsmanager das Verzeichnis C:\FlashSites der Liste der vertrauenswürdigen Pfade hinzufügen. Wenn Sie anschließend SWF-Dateien im Verzeichnis C:\FlashSites oder einem seiner Unterverzeichnisse anzeigen, platziert Flash Player diese SWF-Dateien in der Sandbox für lokale vertrauenswürdige Dateien, so dass durch die Sicherheitsregeln keine Probleme entstehen. Danach dürfen Sie jedoch keine SWF-Dateien aus nicht vertrauenswürdigen Quellen in diesem Verzeichnis platzieren! Wenn Sie Ihre eigenen lokalen SWF-Dateien getrennt von den nicht vertrauenswürdigen SWF-Dateien anderer Autoren aufbewahren, können Sie dieselben verbesserten Schutzmaßnahmen nutzen wie alle Endbenutzer von Flash Player.
Angenommen, Sie haben im Einstellungsmanager ein vertrauenswürdiges Verzeichnis konfiguriert. Ihre eigene Arbeit wird jetzt nicht mehr durch sicherheitsspezifische Probleme unterbrochen. Sie müssen Ihre SWF-Dateien jedoch mit Kollegen gemeinsam nutzen, wie beispielsweise mit HTML-Autoren, Flex-Entwicklern, Bitmap-Erstellern und anderen. Oder Sie möchten Ihre SWF-Dateien Managern oder Kunden präsentieren. Vermutlich haben nicht alle diese Personen vertrauenswürdige Verzeichnisse auf ihren Computern eingerichtet. Wenn diese Personen Ihre SWFs als lokale Dateien öffnen und die SWFs versuchen, mit HTML-Seiten oder dem Internet zu kommunizieren (beispielsweise durch Aufruf von getURL), können die Regeln für die lokale Sicherheit deshalb verhindern, dass Ihr Inhalt bei der lokalen Vorschau wie beabsichtigt funktioniert. Und wenn diese anderen Benutzer nicht die Datei FlashAuthor.cfg auf ihren Computern installiert haben und Ihre SWF-Dateien mit Version 8 oder neuer erstellt wurden, wird nicht einmal ein Warndialogfeld eingeblendet, in dem die Benutzer über den Grund der Probleme informiert werden.
Für diese Probleme, die bei der gemeinsamen Nutzung von Dateien auftreten können, gibt es leider keine einfache Lösung. Das Grundproblem lässt sich folgendermaßen zusammenfassen: Wenn Flash Player auf den Computern Ihrer Kollegen ausgeführt wird, kann das Programm nicht zwischen Ihren (vorübergehend) lokalen SWF-Dateien und möglicherweise nicht vertrauenswürdigen SWF-Dateien unterscheiden, die aus dem Internet heruntergeladen wurden.
Am besten lässt sich dieses Problem beheben, indem Sie Ihre SWF-Dateien auf einem HTTP-Testserver ablegen und dann Links angeben, anstatt Ihre SWF-Dateien in Form von Dateien zur Verfügung zu stellen. Auch diese Lösung ist jedoch in manchen Fällen unpraktisch oder nicht realisierbar, beispielsweise wenn Sie keinen privaten HTTP-Server haben oder wenn Sie Ihre SWF-Dateien mit Personen außerhalb des eigenen Netzwerks gemeinsam nutzen müssen und dazu keine öffentlichen Server verwenden möchten. In diesen Fällen müssen Sie andere Möglichkeiten in Betracht ziehen:
Die jeweils optimale Lösung richtet sich nach Ihrer konkreten Situation.
Die neuen Regeln für die lokale Sicherheit sollten für Endbenutzer von Flash Player kaum Auswirkungen haben. Es ist jedoch möglich, dass einige Benutzer über lokale Flash-Anwendungen verfügen, die eine Kommunikation mit dem Internet vorsehen. Nachdem diese Benutzer einen Upgrade auf Flash Player 8 durchgeführt haben, können Dialogfelder eingeblendet werden, die die Benutzer auf mögliche Sicherheitsrisiken hinweisen.
In diesem Fall haben die Benutzer folgende Möglichkeiten: Sie können das Problem ignorieren, sich zur Problembehebung an den Hersteller der Anwendung wenden oder versuchen, das Problem selbst zu beheben.
Um das Problem selbst zu beheben, müssen die Benutzer im Warndialogfeld auf die Schaltfläche Einstellungen klicken. Dadurch wird der Einstellungsmanager aufgerufen. Hier können Benutzer Einzelheiten zur lokalen Sicherheit lesen oder Bearbeiten > Hinzufügen und dann einen lokalen Pfad auswählen, der als vertrauenswürdig eingestuft werden soll. Häufig ist es nicht einfach, zu bestimmen, welcher Pfad als vertrauenswürdig eingestuft werden muss. In einigen Fällen muss nur der Pfad als vertrauenswürdig eingestuft werden, der im Warndialogfeld genannt wurde, aber häufig sind mehrere SWF-Dateien in einer Anwendung betroffen. In solchen Fällen muss eventuell das ganze Verzeichnis, das diese SWFs enthält, als vertrauenswürdig eingestuft werden. Nach jedem Versuch muss der Benutzer die ursprüngliche Anwendung neu starten, beispielsweise durch Aktualisierung des Browsers.
Im Einstellungsmanager haben Benutzer auch die Möglichkeit, die Option Immer zulassen auszuwählen, damit alle SWF-Dateien aus Version 7 und älteren Versionen als vertrauenswürdig gelten. Dies ist zwar einfacher als die Bestimmung der vertrauenswürdigen Pfade, bietet jedoch nur ein geringeres Maß an Sicherheit.
Angenommen, in Ihrer Anwendung werden lokale SWF-Dateien eingesetzt, und in Flash Player werden Sicherheitsdialogfelder eingeblendet, die die Benutzer bei der Anzeige bestimmter Teile der Anwendung auf potenzielle Sicherheitsrisiken hinweisen. Gehen wir davon aus, dass es sich bei Ihrer Anwendung um ein Hybrid-Hilfesystem handelt, da bei solchen Anwendungen häufig lokale SWF-Dateien zum Einsatz kommen: Das Hilfesystem besteht aus HTML- und SWF-Dateien, die über getURL und möglicherweise auch fscommand miteinander kommunizieren.
Im ersten Schritt sollte der Schweregrad des Problems bestimmt werden. Handelt es sich um eine kritische Komponente in einer wichtigen Anwendung und eine Fehlfunktion mit schwerwiegenden Folgen oder um ein relativ unwichtiges Problem in einem Hobbyprojekt? Wären Sie bereit, korrigierte Dateien an alle Benutzer zu verteilen? Häufig werden Sie diese Fragen bejahen, doch sollten Sie stets die Notwendigkeit von Korrekturmaßnahmen sicherstellen, bevor Sie Zeit dafür investieren.
In manchen Fällen können Sie die Benutzer einfach anweisen, den Einstellungsmanager aufzurufen und das Verzeichnis, in dem sich das Hilfesystem befindet, als vertrauenswürdig einzustufen. Dies kann jedoch für einige Benutzer zu viele Arbeitsschritte nach sich ziehen. Auch sind manche Benutzer unsicher, wenn sie die Auswirkungen der Sicherheitsänderungen nicht verstehen.
Eine andere Möglichkeit besteht darin, die SWF-Dateien in der Sandbox Lokal mit Netzwerk neu zu veröffentlichen oder sie mit dem Dienstprogramm Local Content Updater* zu verarbeiten. Wenn die Sicherheitsverletzungen des Inhalts ausschließlich auf Aufrufe von getURL zurückzuführen sind, sollte dies ausreichend sein. Wenn jedoch zwischen den SWF- und HTML-Dateien ein Cross-Scripting über fscommand, getURL("javascript:...") oder andere Hybrid-Skriptoperationen ausgeführt wird, reicht die Sandbox Lokal mit Netzwerk nicht aus, um den früheren Status der Anwendung wiederherzustellen, sondern Sie müssen die SWF-Dateien in der Sandbox Lokal vertrauenswürdig platzieren.
Wenn die Benutzer über gute technische Kenntnisse verfügen, können Sie ihnen eine FlashPlayerTrust-Datei zur Verfügung stellen, die in einem bestimmten Verzeichnis platziert werden muss. Als Alternative können Sie auch ein kleines Skript oder Programm erstellen, das die FlashPlayerTrust-Datei automatisch im geeigneten Verzeichnis erstellt. Wenn Sie wissen, wo Ihre SWF-Dateien installiert werden, können Sie einfach das entsprechende Verzeichnis als vertrauenswürdig einstufen. Wenn die Benutzer jedoch bei der Installation nicht das Standardverzeichnis verwendet haben, müssen die Benutzer eventuell das Installationsverzeichnis angeben oder ihr Dateisystem nach Ihren SWF-Dateien durchsuchen.
Im letzten Szenario erstellen Sie eine lokale SWF-Anwendung, die Daten regelmäßig mit einem HTTP-Server synchronisieren soll und zudem als lokaler Aufbewahrungsort für diese Daten dient. Bei diesen Daten kann es sich beispielsweise um ein Adressbuch handeln, so dass wir uns diese Anwendung als "gelegentlich verbundenen Kontaktmanager" vorstellen können.
Angenommen, Sie benötigen die Berechtigung Im Netzwerk senden , aber nicht die Berechtigung Lokal lesen, weil Sie beispielsweise keine lokalen XML-Dateien für Ihre Konfiguration lesen müssen. Deshalb wählen Sie beim Veröffentlichen der SWF-Datei(en) in den Flash-Veröffentlichungsoptionen unter Sicherheit bei lokaler Wiedergabe die Option Nur auf Netzwerk zugreifen. Jetzt können Ihre SWF-Dateien getURL, XML.load und andere HTTP-Operationen durchführen.
Nun stellen Sie eine Verbindung zwischen Ihrer Anwendung und der HTTP-Datenquelle her, um die Synchronisierung vorzunehmen. Sie können beispielsweise XML.sendAndLoad() zum Austausch einfacher XML-Daten verwenden. Da es sich bei XML.sendAndLoad um eine Operation des Typs Im Netzwerk lesen handelt, muss auf dem HTTP-Server, mit dem Sie die Daten synchronisieren, eine Richtliniendatei vorhanden sein. Die Richtliniendatei soll nicht den ganzen HTTP-Server, sondern nur die relevanten Daten regeln. Deshalb platzieren Sie die Richtliniendatei neben der XML-Datenquelle und rufen System.security.loadPolicyFile in der Client-SWF auf, wobei Sie den Speicherort der Richtliniendatei angeben. Die Richtliniendatei sieht folgendermaßen aus:
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Die Richtliniendatei muss alle Verzeichnisse ("*") als vertrauenswürdig betrachten, damit die SWF-Dateien in der Sandbox Lokal mit Netzwerk Daten vom Server laden können, gemäß dem Prinzip für globale Berechtigungen.
Damit sollte das Problem gelöst sein.
