In Flash Player 8 hat Macromedia das Sicherheitsmodell geändert, das auf lokalen Flash-Inhalt angewendet wird. Standardmäßig gelten für Flash-Anwendungen, die nicht über HTTP, sondern von einem lokalen Dateisystem ausgeführt werden, in Flash Player 8 weniger Berechtigungen als in Flash Player 7. Das neue Modell wird auf den Flash-Inhalt aller Versionen angewendet. Deshalb ist nicht nur neu erstellter Inhalt betroffen, sondern möglicherweise auch Inhalt, der vor der Einführung von Flash Player 8 veröffentlicht wurde. In diesem Artikel wird beschrieben, wie Sie die meisten Probleme beheben, die sich aus diesen Änderungen ergeben können.

Zusätzlich zum geänderten Sicherheitsmodell gelten in Flash Player 8 auch einige weitere Einschränkungen und neue Sicherheitsfunktionen. Auch diese Änderungen werden in diesem Artikel beschrieben, doch die Änderungen an der lokalen Sicherheit sind das wichtigste Sicherheitsthema in Flash Player 8.

Hinweis: Die Änderungen an der lokalen Sicherheit haben keine Auswirkungen auf Flash-Inhalt, der über HTTP bereitgestellt wird. Der Großteil des Flash-Inhalts wird über HTTP bereitgestellt und ist deshalb von diesen Änderungen nicht betroffen.

Neue Einschränkungen

Im Folgenden werden die neuen Einschränkungen in Bezug auf den Flash-Inhalt aufgelistet:

Lokale Sandboxen: Standardmäßig haben lokale SWF-Dateien nicht mehr die Möglichkeit, Verbindungen mit dem Internet herzustellen oder über HTTP oder mit lokalen HTML-Dateien zu kommunizieren. Wenn SWF-Dateien der Version 7 oder einer früheren Version versuchen, eine solche Aktion durchzuführen, werden die Benutzer in einem Warndialogfeld darauf hingewiesen, dass die jeweilige Aktion nicht möglich ist. Die Anzeige dieses Dialogfelds sowie Funktionsfehler bei vorhandenem Inhalt können von Endbenutzern oder Flash-Entwicklern durch die Erteilung entsprechender Berechtigungen vermieden werden.
Einschränkungen beim Laden: SWF- und HTML-Dateien von nicht lokalen URLs können keinen Inhalt SWF, HTML, PNG usw. mehr von lokalen Pfaden laden.
Speichern des Inhalts von Dritten: Flash Player-Benutzer können jetzt verhindern, dass die SWF-Dateien von Dritten also Dateien, die nicht von der in der Browser-Adressleiste gezeigten Domäne stammen permanente gemeinsame Objekte lesen oder schreiben können. Diese Einschränkung gilt nicht standardmäßig, sondern muss konkret vom Benutzer angewendet werden.
Standardwert für allowScriptAccess: Bei SWF-Dateien ab Version 8 hat der HTML-Parameter allowScriptAccess standardmäßig den Wert "sameDomain" anstelle von "always". SWF-Dateien, die mit Version 7 oder einer früheren Version erstellt wurden, sind davon nicht betroffen. Der Parameter allowScriptAccess steuert, ob SWF-Dateien JavaScript in HTML-Seiten aufrufen können.

Neue Sicherheitsfunktionen

Im Folgenden werden die neuen Sicherheitsfunktionen für Flash-Inhalt aufgelistet Sicherheitsinformationen zu Flash Player 7 finden Sie im Abschnitt zu den Sicherheitsänderungen in Macromedia Flash Player 7 :

Platzhalter in allowDomain: Für System.security.allowDomain kann jetzt das Platzhalterargument "*" angegeben werden, das den Zugriff für SWF-Dateien aus jeder Domäne ermöglicht.

Genauere Berechtigungen: System.security.allowDomain und System.exactSettings gelten jetzt nur für die SWF-Datei, von der sie aufgerufen werden, nicht für die ganze Domäne der aufrufenden SWF-Datei. Da dies nur neuen Inhalt ab Version 8 betrifft, ist die Abwärtskompatibilität gewährleistet.

Sichere permanente gemeinsame Objekte: Über HTTPS geladene SWF-Dateien können jetzt SharedObject-Objekte erstellen, auf die nur SWF-Dateien zugreifen können, die ebenfalls über HTTPS geladen werden. Dies spiegelt die Funktionsweise von Browser-Cookies wider und schützt die Daten in gemeinsamen Objekten vor Snooping und Änderungsbedrohungen. Vorhandene gemeinsame Objekte sind nicht betroffen.

Gründe für die Änderung der lokalen Sicherheit

Die Änderungen an der lokalen Sicherheit in Flash Player 8 haben einen Hauptgrund: Wenn Benutzer SWF-Dateien auf ihre Computer herunterladen, soll gewährleistet sein, dass Flash Player keine schädlichen Auswirkungen oder Aktivitäten dieser SWF-Dateien zulässt. Das Herunterladen und Ausführen von SWF-Dateien soll wie beim Speichern von JPEG- oder TXT-Dateien ohne Sicherheitsbedenken möglich sein, so dass die Benutzer nicht wie im Falle von ausführbaren Dateien besondere Vorsicht walten lassen müssen.

In Flash Player 7 und älteren Versionen wurden lokale SWF-Dateien unter dem Gesichtspunkt eines Autors von Flash-Inhalt behandelt: Eine lokale SWF-Datei ist meist nur eine temporäre, lokale Datei, die schließlich im Internet veröffentlicht wird. Unter diesem Gesichtspunkt besteht kein Grund, das Aktionsspektrum einer lokalen SWF-Datei einzuschränken. Wenn eine SWF-Datei jedoch von einem Benutzer heruntergeladen und ausgeführt wird, der kein Flash-Autor ist, verfügt dieser Benutzer eventuell nicht über ausreichend Kenntnisse über den Ursprung der Datei, um sie als vertrauenswürdig einstufen zu können. In Flash Player 7 und früheren Versionen war es möglich, dass böswillige Dritte einen Benutzer dazu veranlassten, eine SWF-Datei herunterzuladen und auszuführen, die dann als lokale SWF-Datei zwei Berechtigungen kombinieren und missbräuchlich einsetzen konnte: Die SWF-Datei konnte Textdateien von bekannten oder angenommenen Speicherorten im Dateisystem des Benutzers lesen – beispielsweise mit XML.load – und dann den Inhalt dieser Dateien an den Angreifer zurück senden. Dieses so genannte Snooping soll durch die Änderungen an der lokalen Sicherheit in Flash Player 8 verhindert werden.

Der langfristige Erfolg von Flash ist maßgeblich darauf zurückzuführen, dass in allen neuen Flash Player-Versionen die Abwärtskompatibilität mit vorhandenem Flash-Inhalt weitgehend gewährleistet ist. Bei Sicherheitsänderungen ist es jedoch manchmal nicht möglich, die Abwärtskompatibilität einzuhalten, was für Entwickler und Benutzer von Flash gleichermaßen ärgerlich ist. Zahlreiche Benutzer erinnern sich vermutlich noch an die Inhaltsänderungen, die durch die Sicherheitsänderungen in Flash Player 7 erforderlich wurden. Macromedia ist sich durchaus bewusst, dass Sicherheitsänderungen für unsere Kunden mit Unannehmlichkeiten verbunden sein können, und nimmt solche Änderungen daher nur nach reiflicher Überlegung vor. Wir bitten in diesem Zusammenhang um Ihr Verständnis.

Trotz der potenziellen Unannehmlichkeiten ist eine Verbesserung des Sicherheitsmodells für eine Plattformtechnologie wie Flash unerlässlich. Die weite Verbreitung von Flash Player ist letztendlich auch ein Grund, warum Flash für Kunden so wertvoll ist. Ein hohes Maß an Sicherheit ist die Voraussetzung dafür, dass Privatanwender und Unternehmen Flash Player auch in Zukunft installieren und aktualisieren. Rückblickend wäre es vermutlich besser gewesen, schon in früheren Versionen von Flash Player sicherere Regeln für lokalen Flash-Inhalt zu implementieren. Doch lassen sich neue Sicherheitsrisiken genauso schwer prognostizieren wie die Einsatzgebiete von Flash, so dass die geeignete Funktionalität manchmal erst im Laufe mehrerer Versionen realisiert werden kann.

Die gute Nachricht ist, dass die Änderungen in Flash Player 8 sich auf wesentlich weniger Inhalt auswirken sollten als dies bei den Änderungen in Flash Player 7 der Fall war. Die Änderungen in Flash Player 7 betrafen auch Inhalt, der im Internet bereitgestellt wurde. Dagegen wirken sich die Änderungen in Flash Player 8 nur auf Inhalt aus, der in Form von lokalen Dateien zur Verfügung steht, was insgesamt gesehen nur ein relativ kleiner Teil des Inhalts ist. Mit Millionen von Flash-Implementierungen weltweit ist zwar auch "relativ klein" noch sehr viel, doch insgesamt sollten wesentlich weniger Entwickler betroffen sein als bei den Änderungen an Flash Player 7.

Lokale Sicherheit – Grundlagen

In Flash Player 7 und früheren Versionen konnten lokale SWF-Dateien also Dateien, die über einen lokale Pfad vom Dateisystem eines Benutzers geladen werden uneingeschränkt die meisten Vorgänge durchführen, die normalerweise unter die Sicherheitsregeln von Flash Player fallen. Zum Beispiel: Eine über HTTP geladene SWF-Datei ist standardmäßig nur berechtigt, Text mit XML.load aus ihrer eigenen Ursprungsdomäne zu laden, während eine lokale SWF-Datei in Flash Player 7 berechtigt war, Text mit XML.load von jeder HTTP-URL oder jedem Pfad des lokalen Dateisystems zu laden.

Sie können sich das Lesen einer Textdatei von einem lokalen Pfad als Berechtigung namens Lokal lesen vorstellen. Berücksichtigen Sie zudem, dass alle SWF-Dateien in Flash Player 7 die zusätzliche Berechtigung Im Netzwerk senden hatten, mit der alle Daten an jeden Ort im Internet gesendet werden können, beispielsweise über einen HTTP POST-Vorgang mit LoadVars.send . Die Kombination der Berechtigungen Lokal lesen und Im Netzwerk senden für eine lokale SWF-Datei, die ein Endbenutzer von einer nicht vertrauenswürdigen Quelle heruntergeladen hat, ergibt folgende Situation: Die lokale SWF-Datei könnte auf dem Computer des Benutzers gespeicherte Textdateien lesen und den Inhalt an einen Ort im Internet zurücksenden – und zwar ganz ohne Wissen des Benutzers.

In Flash Player 8 gelten kurz ausgedrückt die folgenden Regeln für lokale SWF-Dateien: Standardmäßig verfügen lokale SWF-Dateien noch über die Berechtigung Lokal lesen, aber nicht mehr über die Berechtigung Im Netzwerk senden. Sie sind also nicht berechtigt, mit dem Internet oder einem HTTP-Server zu kommunizieren. Durch Ändern einer Einstellung in der SWF-Datei kann der Flash-Autor der SWF-Datei die Berechtigung Im Netzwerk senden erteilen, wobei jedoch die Berechtigung Lokal lesen verloren geht. Schließlich haben Autoren und Benutzer noch die Möglichkeit, Flash Player so zu konfigurieren, dass eine SWF-Datei den vertrauenswürdigen Status erhält. Dadurch verfügt die SWF-Datei über beide Berechtigungen, also genau dieselben Berechtigungen wie in Flash Player 7.

Betroffener Inhalt

Zwei Faktoren bestimmen, welcher Flash-Inhalt von diesen Änderungen betroffen ist: ob es sich um lokalen Inhalt handelt und in welchem Flash Player-Typ der Inhalt ausgeführt wird.

Betroffen sind SWF-Dateien, die von lokalen Pfaden geladen werden. Dazu gehören unter anderem die folgenden URL-Beispiele:

c:\temp\my.swf
file:///c /temp/my.swf
/temp/my.swf
file:///temp/my.swf
\\server\share\my.swf
file:////server/share/my.swf
Relative URLs, die von lokalen SWF-Dateien geladen werden

Die Auswirkungen auf die verschiedenen Flash Player-Typen richten sich nach unterschiedlichen Bedingungen:

Die Webbrowser-Player ActiveX-Steuerelement und Plug-In-Player erzwingen die Regeln für die lokale Sicherheit grundsätzlich bei der Verwendung in einem Webbrowser.
Die Webbrowser-Player erzwingen die Regeln für die lokale Sicherheit nicht immer, wenn es sich bei der Anwendung nicht um einen Browser handelt. Wenn Sie mit einer Anwendung arbeiten, in der einer dieser Player eingebettet ist, lesen Sie den Abschnitt "Flash Player-Einbettung und lokale Sicherheit".
Die eigenständigen Player erzwingen die Regeln für die lokale Sicherheit.
Flash-Projektoren, die in der Authoring-Anwendung Macromedia Flash und in den eigenständigen Playern erstellt werden können, erzwingen die Regeln für die lokale Sicherheit nicht. Grund hierfür ist, dass es sich um ausführbare Anwendungen handelt, bei denen die Benutzer im Allgemeinen wissen, dass besondere Vorsicht geboten ist.
Die Authoring-Player in Flash erzwingen die Regeln für die lokale Sicherheit nicht, da sie nur zum Testen des Inhalts in der Entwicklungsphase verwendet werden, nicht zum Wiedergeben von Inhalt aus dem Internet.

Sandbox-Typen

In Flash Player 8 werden alle SWF-Dateien und HTML-Dateien zum Zweck des SWF-HTML-Scripting in einer von vier Sandboxen platziert:

Remote. Alle Dateien, die nicht von lokalen URLs stammen, werden in einer Remote-Sandbox platziert. Es gibt zahlreiche solche Sandboxen, und zwar je eine für jede Internet- oder Intranet-Domäne, von der Dateien geladen wurden. Diese Sandboxen wurden in Flash Player 6 eingeführt und haben sich in Flash Player 8 nicht geändert.
Lokal mit Dateisystem. Dies ist die Standard-Sandbox für lokale Dateien in Flash Player 8. SWF-Dateien in dieser Sandbox haben keine Möglichkeit, mit dem Internet oder HTTP-Servern zu kommunizieren. Beispielsweise können sie HTTP-URLs nicht an loadMovie , getURL oder XML.load übergeben. Da diese Vorgänge in Flash Player 7 zulässig waren, funktioniert älterer Inhalt möglicherweise nicht mehr wie beabsichtigt, wenn eine SWF-Datei der Version 7 oder einer früheren Version nach einem Upgrade von Flash Player 7 auf Flash Player 8 versucht, auf das Internet zuzugreifen. In diesem Fall weist Flash Player 8 den Endbenutzer in einem Warndialogfeld darauf hin, dass der Versuch, mit dem Internet zu kommunizieren, fehlgeschlagen ist. Dieses Warndialogfeld enthält eine Schaltfläche, über die der Benutzer auf den Einstellungsmanager zugreifen und dem jeweiligen Inhalt den Status Lokal vertrauenswürdig zuweisen kann siehe unten .
Lokal mit Netzwerk. SWF-Dateien in dieser Sandbox können über HTTP kommunizieren, aber nicht von lokalen Dateisystemen lesen. SWF-Dateien jeder Version können sich über ein Flag in der SWF-Datei selbst in diese Sandbox platzieren, so dass keine Benutzerinteraktion erforderlich ist, um eine SWF-Datei in diese Sandbox zu platzieren. Das Flag kann über die Veröffentlichungseinstellungen in Flash 8 oder über das Programm Local Content Updater eingestellt werden, ein kostenloses Dienstprogramm für die SWF-Nachbearbeitung, das unter macromedia.com erhältlich ist.
Lokal vertrauenswürdig. Für diese Sandbox gelten keine Einschränkungen. Sie bietet dieselben Berechtigungen, über die alle lokalen Dateien in Flash Player 7 verfügten. Durch Autorisierung des Endbenutzers kann jede lokale Datei in dieser Sandbox platziert werden. Diese Autorisierung kann auf zwei verschiedene Arten erfolgen: interaktiv über den Einstellungsmanager oder nicht interaktiv über ein ausführbares Installationsprogramm, das Flash Player-Konfigurationsdateien auf dem Computer des Benutzers erstellt.

Zu diesem Zeitpunkt kann es hilfreich sein, die Diagramme im Anhang einzusehen, die die lokale Sicherheit veranschaulichen siehe Lokale Sicherheit – Diagramme .

Wenn eine lokale SWF-Datei Zugriff auf das Internet oder einen HTTP-Server im Intranet benötigt, kommen zwei lokale Sandboxen in Frage. Die Sandbox Lokal mit Netzwerk lässt sich einfacher umsetzen, und alle erforderlichen Konfigurationsdaten sind in der SWF-Datei selbst integriert. Die Sandbox Lokal vertrauenswürdig ist zwar leistungsstärker und bietet mehr Berechtigungen, doch ist der Umsetzungsaufwand höher, und die Konfigurationsdaten sind nicht in der SWF-Datei selbst enthalten. Nachdem die Regeln für die lokale Sicherheit ausführlich beschrieben wurden, befasst sich der Rest dieses Artikels mit der Frage, welche der beiden Alternativen geeignet ist.

Globale Berechtigungen

Da lokale Dateien in Flash Player 8 nicht mehr über uneingeschränkte Berechtigungen verfügen, können Situationen auftreten, in denen den lokalen Dateien explizit Flash-Berechtigungen erteilt werden können. Dies wird im nächsten Abschnitt erläutert.

Im Allgemeinen gilt in Flash Player das Prinzip, dass zur Erteilung von Berechtigungen für lokale Dateien globale Berechtigungen erforderlich sind. Wenn eine Remote-SWF-Datei beispielsweise zum Scripting für eine SWF-Datei in der Sandbox Lokal mit Netzwerk zur Verfügung stehen möchte, muss sie System.security.allowDomain "*" aufrufen. So erhalten andere geladene SWF-Dateien die Möglichkeit, die Remote-SWF-Datei zum Scripting zu verwenden. Flash Player bietet keine Möglichkeit, die Berechtigung nur lokalen Dateien zu erteilen, sondern die Berechtigung kann nur allen Dateien erteilt werden. Grund hierfür ist, dass Flash Player den Ursprung einer lokalen Datei nicht bestimmen kann – die Datei kann theoretisch von überall her stammen. Deshalb ist es nicht empfehlenswert, einer lokalen Datei die Berechtigung zum Ausführen einer Aktion zu erteilen, es sei denn, der Ursprungsort der Datei ist nicht von Interesse.

Sie sollten System.security.allowDomain "*" nur aufrufen, wenn die jeweilige SWF-Datei keine vertraulichen Daten enthält. Rufen Sie System.security.allowDomain "*" nicht als allgemeine Lösung für Sicherheitsprobleme auf, da so Sicherheitsmaßnahmen verloren gehen, die für Ihren Inhalt möglicherweise sehr wichtig sind! Bevor Sie globale Berechtigungen erteilen, sollten Sie sich genau überlegen, welche Auswirkungen dies hat.

Lokale Sandboxen

In diesem Abschnitt werden die lokalen Sandboxen beschrieben, in die SWF-Dateien platziert werden.

Berechtigungen

In Flash Player sind die folgenden Berechtigungstypen für lokale Dateien definiert:

Lokal lesen. Diese Berechtigung ist für SWF-Dateien in der Sandbox Lokal mit Dateisystem verfügbar, nicht aber für SWF-Dateien in der Sandbox Lokal mit Netzwerk. Die Berechtigung ermöglicht das Laden von Daten aus externen Dateien in ActionScript-Variablen, wobei die Daten aus Dateien stammen, die sich im lokalen Dateisystem befinden. Beispiele für lokale URLs sind im Abschnitt "Betroffener Inhalt" aufgelistet. Die folgenden Ladevorgänge für Daten sind betroffen:
- XML.load, XML.sendAndLoad
- LoadVars.load, LoadVars.sendAndLoad, loadVariables, loadVariablesNum, MovieClip.loadVariables
- Import eines Symbols aus der Bibliothek einer anderen SWF-Datei
Im Netzwerk senden. Diese Berechtigung ist für SWF-Dateien in der Sandbox Lokal mit Netzwerk verfügbar, nicht aber für SWF-Dateien in der Sandbox Lokal mit Dateisystem. Diese Berechtigung ermöglicht das Senden von Daten oder Anforderungen an Internet-Adressen oder HTTP-Server. Dazu gehören die folgenden Vorgänge mit nicht lokalen URLs:
- XML.load, XML.send, XML.sendAndLoad
- LoadVars.load, LoadVars.send, LoadVars.sendAndLoad, loadVariables, loadVariablesNum, MovieClip.loadVariables
- XMLSocket.connect
- NetConnection.call (Flash Remoting)
- Import eines Symbols aus der Bibliothek einer anderen SWF-Datei
- getURL, MovieClip.getURL
- loadMovie, loadMovieNum, MovieClip.loadMovie, MovieClipLoader.loadClip
- Sound.loadSound
Im Netzwerk lesen. SWF-Dateien in der Sandbox Lokal mit Netzwerk können Vorgänge mit der Berechtigung Im Netzwerk senden ausführen. Einige Vorgänge des Typs Im Netzwerk senden sind unidirektional, das heißt, es werden Daten gesendet, aber keine Antworten empfangen; andere sind Anforderungen, auf die eine Antwort zurück gesendet wird. Letztere sind Vorgänge des Typs Im Netzwerk lesen, eine untergeordnete Gruppe von Im Netzwerk senden. SWF-Dateien in der Sandbox Lokal mit Netzwerk können Vorgänge des Typs Im Netzwerk lesen versuchen, wobei jedoch eine Berechtigung von der Ursprungsdomäne der Daten erforderlich ist. Dies sind die folgenden Vorgänge mit nicht lokalen URLs:
- XML.load, XML.sendAndLoad
- LoadVars.load, LoadVars.sendAndLoad, loadVariables, loadVariablesNum, MovieClip.loadVariables
- XMLSocket.connect
- NetConnection.call (Flash Remoting)
- Import eines Symbols aus der Bibliothek einer anderen SWF-Datei
SWF-HTML. Dies sind Vorgänge, die das Scripting zwischen SWF- und HTML-Dateien ermöglichen. Bei den drei lokalen Sandboxen verfügen nur lokale vertrauenswürdige Dateien über die SWF-HTML-Berechtigung, um potenzielle Diskrepanzen zwischen den Sicherheitsmodellen von Flash Player und Webbrowsern zu vermeiden. Zu diesen Vorgängen gehören:
- SWF-zu-HTML-Vorgänge:

        fscommand
getURL("javascript:...")
ExternalInterface.call
          
    

HTML-zu-SWF-Vorgänge:
Die JavaScript-API SetVariable, GotoFrame usw.
Aufruf einer mit ExternalInterface.addCallback erstellten Rückruffunktion

SWF-Dateien in die Sandbox "Lokal mit Netzwerk" platzieren

Eine lokale SWF-Datei wird in diese Sandbox platziert, wenn sie das Flag UseNetwork enthält. Dieses Flag kann zwar in jede SWF-Datei jeder Version platziert werden, ist jedoch nur ab Flash Player 8 von Bedeutung. Das Flag wird mit zwei Verfahren festgelegt:

Wählen Sie bei der Veröffentlichung in Flash 8 im Dialogfeld Einstellungen für Veröffentlichungen die Registerkarte Flash aus, suchen Sie die Option Sicherheit bei lokaler Wiedergabe im unteren Bereich des Dialogfelds, und wählen Sie Nur auf Netzwerk zugreifen siehe Abbildung 1 .

Abbildung 1. Sicherheit bei lokaler Wiedergabe nur für Zugriff auf Netzwerk eingestellt

Wenn Sie nicht über Flash 8 verfügen oder lieber mit bereits veröffentlichten SWF-Dateien arbeiten anstatt sie neu zu veröffentlichen, können Sie das Befehlszeilendienstprogramm Flash Local Content Updater verwenden, das unter macromedia.com kostenlos zum Download bereitsteht. Dieses Dienstprogramm kann das UseNetwork-Flag für eine oder mehrere SWF-Dateien hinzufügen und entfernen oder überprüfen, ob das Flag vorhanden ist. Local Content Updater ist für Windows, Mac OS X und Linux sowie als Quellcode verfügbar.

Das UseNetwork-Flag betrifft weder SWF-Dateien, die über HTTP geladen werden und immer in Remote-Sandboxen platziert werden, noch SWF-Dateien, die vom Benutzer als vertrauenswürdig eingestuft wurden und immer in der lokalen vertrauenswürdigen Sandbox platziert werden. Das UseNetwork-Flag wirkt sich nur auf SWF-Dateien aus, die sonst in der Sandbox Lokal mit Dateisystem platziert würden.

Dateien zur Platzierung in der lokalen vertrauenswürdigen Sandbox konfigurieren

Eine lokale SWF-Datei oder HTML-Datei wird in dieser Sandbox platziert, wenn sie sich in einem lokalen Pfad befindet, der in der lokalen Konfiguration des Benutzers als vertrauenswürdig eingestuft wurde. Es ist möglich, die Pfade einzelner Dateien oder ganze Verzeichnisse als vertrauenswürdig einzustufen. Im letzteren Fall werden alle Dateien und Unterverzeichnisse des ausgewählten Verzeichnisses ebenfalls als vertrauenswürdig betrachtet. Dateien lassen sich mit zwei Verfahren als vertrauenswürdig einstufen:

Einstellungsmanager. Benutzer können die Sicherheitseinstellungen des Einstellungsmanagers aufrufen und vertrauenswürdige Pfade in einer Liste manuell hinzufügen, bearbeiten oder entfernen siehe Abbildung 2 .

Abbildung 2. Sicherheitseinstellungen im Einstellungsmanager von Flash Player

Mit den Optionen Fragen/Zulassen/Verweigern der Sicherheitseinstellungen können Benutzer auch global festlegen, wie Flash Player ältere SWF-Dateien verarbeiten soll SWF-Dateien des Typs Lokal mit Dateisystem aus Version 7 und älteren Versionen . Die Standardeinstellung Fragen bewirkt, dass unzulässige Operationen verhindert werden, wobei aber ein Warndialogfeld eingeblendet wird. Bei Auswahl von Immer zulassen können alle unzulässigen Vorgänge ausgeführt werden, wodurch das Standardverhalten von Flash Player 7 wiederhergestellt wird. Diese Einstellung wirkt sich jedoch nicht auf SWF-Dateien ab Version 8 aus, da sie nur für Inhalt vorgesehen ist, der erstellt wurde, bevor die neuen Regeln für die lokale Sicherheit in Kraft traten. Immer verweigern bewirkt, dass alle unzulässigen Vorgänge verhindert werden, ohne dass ein Warndialogfeld eingeblendet wird.
Hinweis: Die Optionen Fragen/Zulassen/Verweigern regeln nicht nur Situationen der lokalen Sicherheit, sondern auch Situationen in Bezug auf die exakte Übereinstimmung von Domänen, die seit Flash Player 7 auftreten.
FlashPlayerTrust-Konfigurationsdateien. Dies sind einfache Textdateien, in denen vertrauenswürdige Pfade aufgelistet werden. Sie sollen von ausführbaren Installationsprogrammen erstellt werden. Wenn ein Installationsprogramm SWF-Dateien auf dem Computer eines Benutzers installiert, kann es auch Konfigurationsdateien installieren, mit denen die SWF-Dateien als vertrauenswürdig eingestuft werden. Bei diesem Verfahren stuft der Benutzer die einzelnen SWF-Dateien zwar nicht explizit als vertrauenswürdig ein, aber implizit durch Ausführung des Installationsprogramms. Flash Player erkennt solche Konfigurationsdateien an zwei Speicherorten: einer gilt für alle Benutzer des Computers und der andere nur für den aktuellen Benutzer. Der Speicherort für alle Benutzer erfordert Administrationsberechtigungen auf Betriebssystemebene. Dies sind die Speicherorte:
- Windows, alle Benutzer:
  <system>\Macromed\Flash\FlashPlayerTrust
  
  z. B. c:\WINNT\system32\Macromed\Flash\FlashPlayerTrust
- Windows, ein Benutzer:
  <Anwendungsdaten>\Macromedia\Flash Player\#Security\FlashPlayerTrust
  
  z. B. c:\Dokumente und Einstellungen\fred\Anwendungsdaten\Macromedia\Flash Player\#Security\FlashPlayerTrust
- Mac OS, alle Benutzer:
  <app support>/Macromedia/FlashPlayerTrust
  
  z. B. /Library/Application Support/Macromedia/FlashPlayerTrust
- Mac OS, ein Benutzer:
  <app data>/Macromedia/Flash Player/#Security/FlashPlayerTrust
  
  z. B. /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust

Bei diesen Speicherorten handelt es sich nicht um einzelne Dateien, sondern um Verzeichnisse. In diesen Verzeichnissen können beliebig viele Konfigurationsdateien gespeichert werden. Flash Player liest alle darin enthaltenen Dateien. Die Konfigurationsdateien können nicht in Unterverzeichnissen von FlashPlayerTrust gespeichert werden, sondern müssen direkt in den FlashPlayerTrust-Verzeichnissen platziert werden. Die einzelnen Konfigurationsdateien können zwar beliebig benannt werden, doch empfiehlt sich eine produktspezifische Benennung, um Namenskonflikte auszuschließen. Es ist möglich, dass die FlashPlayerTrust-Verzeichnisse nicht auf jedem System vorhanden sind; in diesem Fall müssen sie von den Installationsprogrammen erstellt werden.

Diese Dateien haben eine sehr einfache Syntax: Sie enthalten mehrere lokale Pfade, die jeweils auf einer eigenen Zeile aufgelistet werden. Leerräume und leere Zeilen sind zulässig. Die Dateien können Kommentare enthalten, die durch das Zeichen # eingeleitet werden und zum Ende der Zeile reichen. Anführungszeichen sind für Pfade, die Leerzeichen enthalten, unnötig und verursachen Probleme .

Da in diesen Dateien Dateisystempfade aufgelistet werden, die auf manchen Computern möglicherweise andere Zeichen als ASCII enthalten, ist die Textkodierung der FlashPlayerTrust-Dateien von Bedeutung. Flash Player sucht am Anfang dieser Dateien nach Unicode-BOM-Zeichen Byte Order Mark , erkennt UTF-8- und UTF-16-BOM-Zeichen und interpretiert den Rest der Datei als UTF-8 bzw. UTF-16. Zahlreiche Texteditoren, wie Windows Editor und Mac TextEdit, können Unicode-Textdateien schreiben, die diese BOM-Zeichen enthalten. Wenn Flash Player kein BOM-Zeichen am Anfang einer FlashPlayerTrust-Datei findet, wird die Datei mit der aktuellen Codeseite lokale Standardkodierung des Computers interpretiert.

HTML-Sandboxen

Meist werden SWF-Dateien in Sandboxen platziert, doch Flash Player platziert auch HTML-Dateien in Sandboxen, um die Interaktion zwischen SWF- und HTML-Dateien zu steuern. Für lokale HTML-Dateien sind nur zwei Sandboxen verfügbar: vertrauenswürdig und nicht vertrauenswürdig. Lokale HTML-Dateien sind standardmäßig nicht vertrauenswürdig, können aber genau wie SWF-Dateien als vertrauenswürdig eingestuft werden. Die Sandbox einer lokalen HTML-Datei ist nur für das HTML-zu-SWF-Scripting relevant, beispielsweise mit der JavaScript-API von Flash Player.

Sandbox einer SWF-Datei bestimmen

Eine SWF-Datei kann mit der folgenden schreibgeschützten ActionScript-Eigenschaft den Typ ihrer Sandbox bestimmen:

System.security.sandboxType

Diese Eigenschaft hat einen der vier folgenden Stringwerte:

"remote"
"localWithFile"
"localWithNetwork"
"localTrusted"

Verhalten der Sandbox "Lokal mit Dateisystem"

SWF-Dateien in der Sandbox Lokal mit Dateisystem können Vorgänge des Typs Lokal lesen durchführen, aber weder Vorgänge des Typs Im Netzwerk senden noch SWF-HTML-Operationen.

Wenn Sie eine Debug-Version von Flash Player verwenden, mit dem Debugger in Macromedia Flash verbunden sind und eine SWF-Datei in dieser Sandbox versucht, eine unzulässige Operation durchzuführen, wird im Bedienfeld Ausgabe eine Diagnosemeldung angezeigt, die die fehlgeschlagene Operation beschreibt.

Wenn ein Benutzer eine SWF-Datei mit der Veröffentlichungsversion 7 oder früher in dieser Sandbox wiedergibt und die SWF-Datei versucht, eine unzulässige Operation durchzuführen, wird ein Warndialogfeld eingeblendet. In diesem Warndialogfeld wird der Benutzer darauf hingewiesen, dass der Inhalt wegen der geänderten Regeln für die lokale Sicherheit in Flash Player 8 möglicherweise nicht mehr wie vorgesehen funktioniert.

Abbildung 3. Sicherheitsdialogfeld weist den Benutzer auf Abbruch des Vorgangs hin

Dieses Dialogfeld wird bei jeder Ausführung der Anwendung nur einmal angezeigt. Folgende Operationen schlagen fehl, ohne dass dieses Dialogfeld erneut eingeblendet wird.

Der versuchte Vorgang schlägt fehl, unabhängig davon, welche Schritte der Benutzer im Dialogfeld ausführt. Wenn der Benutzer jedoch auf die Schaltfläche Einstellungen klickt, wird ein neues Fenster mit dem Einstellungsmanager geöffnet. Hier kann der Benutzer den lokalen Inhalt, der die Durchführung der unzulässigen Operation versucht hat, als vertrauenswürdig einstufen. Wenn der Benutzer kurz nach Anzeige des Flash Player Einstellungsmanagers in Abbildung 2 den Befehl Hinzufügen im Einstellungsmanager auswählt, wird in einem Hinweis der Pfad der lokalen SWF-Datei eingeblendet, die versucht hat, die unzulässige Operation durchzuführen (siehe Abbildung 4).

Abbildung 4. Angabe eines vertrauenswürdigen Speicherorts mit einem Hinweis

Der Benutzer kann diesen Pfad einfach in das Textfeld Dieser Website vertrauen kopieren, um die SWF-Datei, die die Anzeige des Dialogfelds ausgelöst hat, als vertrauenswürdig einzustufen. In einigen Fällen ist dies ausreichend, doch manchmal besteht eine Anwendung aus mehreren Dateien, die als vertrauenswürdig eingestuft werden müssen, damit die Anwendung wie vorgesehen funktioniert. Lesen Sie hierzu auch den Abschnitt zu kooperierenden Medien. Der Benutzer muss also versuchsweise mehrere Dateien oder das ganze Verzeichnis der jeweiligen SWF-Datei als vertrauenswürdig einstufen.

Wenn der Benutzer Änderungen am Einstellungsmanager vornimmt, muss die Anwendung neu gestartet werden meist durch Aktualisierung des Browsers , bevor die Änderungen wirksam werden.

In der Dokumentation zu den Sicherheitseinstellungen des Einstellungsmanagers wird der oben beschriebene Arbeitsablauf für Endbenutzer genauer erläutert. Außerdem wird in der TechNote Wie kann ich lokale Flash-Inhalte mit dem Internet kommunizieren lassen? ausführlich beschrieben, wie lokaler Inhalt als vertrauenswürdig eingestuft werden kann.

FlashAuthor.cfg

Das Warndialogfeld zur lokalen Sicherheit wird Endbenutzern nur für SWF-Dateien der Version 7 und früher angezeigt. Dieses Dialogfeld soll Benutzern die Möglichkeit geben, älteren Inhalt vor Flash 8 korrekt zu verwenden, der von den neuen Regeln zur lokalen Sicherheit betroffen ist.

Für Autoren von Flash-Inhalt kann das Sicherheitsdialogfeld jedoch auch eine nützliche Informationsquelle sein, aus der ersichtlich ist, warum Inhalt nicht korrekt funktioniert. Autoren möchten möglicherweise umgehend informiert werden, wenn eine SWF-Datei beliebiger Version versucht, eine Operation durchzuführen, die unter den neuen Regeln der lokalen Sicherheit nicht zulässig ist.

Deshalb installieren verschiedene Authoring-Tools von Macromedia, darunter auch Macromedia Flash 8, eine Datei namens FlashAuthor.cfg. Diese Datei weist Flash Player an, ein Warndialogfeld einzublenden, wenn eine SWF-Datei egal welcher Version in der Sandbox Lokal mit Dateisystem versucht, eine unzulässige Operation durchzuführen. Benutzer können diese Datei auch selbst erstellen. Die Datei kann in einem von zwei Speicherorten platziert werden, jeweils neben den FlashPlayerTrust-Verzeichnissen:

Windows, alle Benutzer:
<system>\Macromed\Flash\FlashAuthor.cfg

z. B. c:\WINNT\system32\Macromed\Flash\FlashAuthor.cfg
Windows, ein Benutzer:
<Anwendungsdaten>\Macromedia\Flash Player\#Security\FlashAuthor.cfg

z. B. c:\Dokumente und Einstellungen\fred\Anwendungsdaten\Macromedia\Flash Player\#Security\FlashAuthor.cfg
Mac OS, alle Benutzer:
<app support>/Macromedia/FlashAuthor.cfg

z. B. /Library/Application Support/Macromedia/FlashAuthor.cfg
Mac OS, ein Benutzer:
<app data>/Macromedia/Flash Player/#Security/FlashAuthor.cfg

z. B. /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashAuthor.cfg

In dieser Datei wird derzeit nur eine Direktive erkannt:

LocalSecurityPrompt=Author

Durch diese Direktive ignoriert Flash Player die SWF-Version bei der Entscheidung, ob das Warndialogfeld in Abbildung 3 angezeigt werden soll.

Die Datei FlashAuthor.cfg kann auch Leerräume enthalten sowie Kommentare, die vom Zeichen # eingeleitet werden und bis zum Ende der Zeile reichen.

Wenn Sie SWF-Inhalt entwickeln, der in Form von lokalen Dateien wiedergegeben werden soll, ist die Direktive LocalSecurityPrompt=Author wahrscheinlich nicht zu empfehlen, da sie verhindert, dass Flash Player das Endbenutzerverhalten genau simuliert. Sie können das autorenspezifische Verhalten deaktivieren, indem Sie die Datei FlashAuthor.cfg so ändern, dass ihr Inhalt nicht LocalSecurityPrompt=Author ist, wie oben gezeigt. Beispielsweise können Sie die oben gezeigte Zeile auskommentieren oder in leicht verständlichen Text ändern, wie:

LocalSecurityPrompt=User

Beachten Sie, dass Macromedia Flash 8 die Datei FlashAuthor.cfg in den Verzeichnissen für alle Benutzer und für einen Benutzer installiert. Wenn FlashAuthor.cfg in beiden Verzeichnissen vorhanden ist, berücksichtigt Flash Player die Kopie im Verzeichnis für einen Benutzer. Bearbeiten Sie also die Datei in diesem Verzeichnis.

Verhalten der Sandbox "Lokal mit Netzwerk"

SWF-Dateien in der Sandbox Lokal mit Netzwerk können Vorgänge des Typs Im Netzwerk senden durchführen, aber weder Vorgänge des Typs Lokal lesen noch SWF-HTML-Operationen.

Wenn Sie eine Debug-Version von Flash Player verwenden, mit dem Debugger in Flash verbunden sind und eine SWF-Datei in dieser Sandbox versucht, eine unzulässige Operation durchzuführen, wird im Bedienfeld Ausgabe eine Diagnosemeldung angezeigt, die die fehlgeschlagene Operation beschreibt.

Für SWF-Dateien in dieser Sandbox wird das Dialogfeld mit der Sicherheitswarnung nicht eingeblendet, da keine Situation möglich ist, in der Inhalt vor Änderung der Regeln für die lokale Sicherheit erstellt werden konnte und sich gleichzeitig in der Sandbox Lokal mit Netzwerk befindet. Alle unzulässigen Vorgänge in dieser Sandbox schlagen fehl, ohne dass eine Warnung für den Endbenutzer angezeigt wird.

SWF-Dateien in der Sandbox Lokal mit Netzwerk können Vorgänge mit der Berechtigung Im Netzwerk senden ausführen. Einige Vorgänge des Typs Im Netzwerk senden sind unidirektional, das heißt, es werden Daten gesendet, aber keine Antworten empfangen; andere sind Anforderungen, auf die eine Antwort zurück gesendet wird. Letztere sind Vorgänge des Typs Im Netzwerk lesen, eine untergeordnete Gruppe von Im Netzwerk senden. Ein Beispiel für einen Vorgang des Typs Im Netzwerk lesen ist XML.load "http://mysite.com/data/schedule.xml" . SWF-Dateien in der Sandbox Lokal mit Netzwerk können Vorgänge mit der Berechtigung Im Netzwerk lesen ausführen. In Übereinstimmung mit dem Prinzip für globale Berechtigungen in Flash Player kann eine SWF-Datei in der Sandbox Lokal mit Netzwerk aber nur Daten aus einer Domäne laden, wenn diese Domäne eine Richtliniendatei bereitstellt, die alle Domänen zum Lesen der relevanten Daten berechtigt, und zwar mit <allow-access-from domain="*" />. Im oben genannten Beispiel benötigt mysite.com eine Richtliniendatei am Standardspeicherort http://mysite.com/crossdomain.xml oder neben den gewünschten Daten http://mysite.com/data/crossdomain.xml . Im letzteren Fall müsste die ladende SWF-Datei den folgenden Aufruf durchführen, um Flash Player über den nicht standardmäßigen Speicherort der Richtliniendatei zu informieren:

System.security.loadPolicyFile("http://mysite.com/data/crossdomain.xml")

Lokale Sicherheit für kooperierende Medien

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.

Tabelle 1. Einschränkungen in Bezug auf Laden und Cross-Scripting zwischen Sandboxen
Sandbox der aufgerufenen SWF	Lokal mit Dateisystem	Lokal mit Netzwerk	Lokal vertrauenswürdig	Remote
	Sandbox der aufrufenden SWF
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

Einschränkungen beim Laden

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. :

Remote-SWFs die über HTTP und andere nicht lokale Protokolle bereitgestellt werden können grundsätzlich keine lokalen SWFs laden.
SWF-Dateien in der Sandbox Lokal mit Netzwerk können keine SWF-Dateien in der Sandbox Lokal mit Dateisystem laden und umgekehrt.
SWF-Dateien in der Sandbox Lokal mit Dateisystem können keine Remote-SWFs laden. Diese Einschränkung ergibt sich aus einer bereits beschriebenen Regel: Das Laden einer Remote-SWF erfordert den Aufruf von loadMovie mit einer Remote-URL. Dies ist eine Operation des Typs Im Netzwerk senden und als solche für SWF-Dateien in der Sandbox Lokal mit Dateisystem nicht zulässig.

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:

Remote-SWFs können getURL nicht mit lokalen URLs aufrufen
SWF-Dateien in der Sandbox Lokal mit Dateisystem können getURL zwar mit lokalen URLs aufrufen, dabei werden jedoch alle Abfrageparameter oder Anker Teile der URL, die auf "?" oder "#" folgen entfernt.

Berechtigungen für das Cross-Scripting

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:

Eine nicht vertrauenswürdige lokale SWF-Datei führt ein Cross-Scripting mit einer lokalen vertrauenswürdigen SWF-Datei durch. Die lokale vertrauenswürdige SWF-Datei muss eine entsprechende Berechtigung erteilen.
Eine SWF-Datei in der Sandbox Lokal mit Netzwerk führt ein Cross-Scripting mit einer Remote-SWF durch. Die Remote-SWF muss eine entsprechende Berechtigung erteilen.
Eine Remote-SWF führt ein Cross-Scripting mit einer anderen Remote-SWF aus einer anderen Domäne aus. Die aufgerufene SWF-Datei muss eine entsprechende Berechtigung erteilen die Regeln für Remote-zu-Remote haben sich seit Flash Player 7 nicht geändert .

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.

Permanente gemeinsame Objekte

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.

Lokale Sicherheit – Szenarios

Die folgenden Szenarios sollen die Auswirkungen der neuen Regeln für die lokale Sicherheit in Flash Player 8 veranschaulichen.

Benutzerszenario: Flash-Autoren und Kollegen

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:

Film in der Flash-Autoring-Anwendung testen. Die Player im Modus Film testen erzwingen keine neuen Regeln für die lokale Sicherheit, so dass in diesem Modus keine Probleme auftreten sollten.
Lokale SWF-Dateien mit eigenständigen Playern oder Browser-Playern anzeigen. Bei diesem Verfahren ist die Wahrscheinlichkeit höher, dass die neuen Regeln Probleme verursachen, beispielsweise wenn eine SWF-Datei getURL mit einer HTTP-URL aufruft.
SWF-Dateien auf einem HTTP-Testserver platzieren und in einem Browser anzeigen. Bei diesem Testverfahren ergeben sich keine Probleme wegen der lokalen Sicherheit, da die SWF-Dateien, die über HTTP angezeigt werden, keine lokalen SWFs sind. Sie fallen stattdessen unter die Flash Player-Regeln für die Remote-Sicherheit, die sich in Flash Player 8 nicht geändert haben.

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:

SWF-Projektoren erstellen
SWF-Dateien mit der Berechtigung Lokal mit Netzwerk anstelle von Lokal mit Dateisystem veröffentlichen
Installationsprogramme für SWF-Projekte erstellen, die FlashPlayerTrust-Dateien einrichten
Konfigurationsanleitungen für den Einstellungsmanager an Kollegen senden
Kollegen bitten, die SWF-Dateien auf eigenen Servern bereitzustellen

Die jeweils optimale Lösung richtet sich nach Ihrer konkreten Situation.

Benutzerszenario: Flash Player-Endbenutzer

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.

Anwendungsszenario: Probleme in einem Hybrid-Hilfesystem beheben

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.

Anwendungsszenario: Gelegentlich verbundener Kontaktmanager

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.

Lokale Sicherheit – Diagramme

In den folgenden Diagrammen werden die bisher beschriebenen Berechtigungen für die lokale Sicherheit übersichtlich dargestellt.

Quellen und Sandboxen

Alle SWF-Dateien werden beim Laden in Flash Player in einer Sandbox platziert. Abbildung 5 zeigt, wie SWF-Dateien je nach Ursprung verschiedenen Sandboxen zugewiesen werden. SWF-Dateien aus dem Netzwerk, wie beispielsweise a.com und b.com, werden immer in einer Sandbox platziert, die der Ursprungsdomäne entspricht.

Abbildung 5. Sandbox-Zuweisungen auf Grundlage der SWF-Quelle

SWF-Dateien aus lokalen Quellen (lokale Dateisysteme oder UNC-Netzwerkpfade) werden in einer von drei Sandboxen platziert. Standardmäßig wird eine lokale SWF-Datei in der Sandbox Lokal mit Dateisystem platziert. Lokale Dateien, die den Netzwerkzugriff angefordert haben, werden in der Sandbox Lokal mit Netzwerk platziert. Lokale Dateien, die als vertrauenswürdig eingestuft wurden (im Einstellungsmanager oder mithilfe von Konfigurationsdateien), werden in der Sandbox Lokal vertrauenswürdig platziert. (In Flash Player 7 und früheren Versionen werden alle lokale Dateien in der Sandbox Lokal vertrauenswürdig platziert.)

Zwischen SWF-Dateien in derselben Sandbox ist eine uneingeschränkte Interaktion möglich. In den Diagrammen weiter unten wird veranschaulicht, wie SWF-Dateien mit den SWFs aus anderen Sandboxen sowie mit Dateisystemen und Servern interagieren können.

Standardberechtigungen

Die Pfeile in Abbildung 5 zeigen die SWF-Quelle. In den folgenden Diagrammen veranschaulichen die Pfeile dagegen den Zugriff. Gestrichelte Pfeile zeigen das Laden von Daten und Konturpfeile das Cross-Scripting. Abbildung 6 zeigt die Berechtigungen der SWF-Dateien, die sich in Standard-Sandboxen befinden.

Abbildung 6. Standardmäßige Sandbox-Zuweisungen und die Standardberechtigungen dieser Sandboxen

Standardmäßig werden lokale SWF-Dateien in der Sandbox Lokal mit Dateisystem platziert. SWF-Dateien in dieser Sandbox können Daten aus Dateien in lokalen Dateisystemen oder UNC-Netzwerkpfaden lesen, beispielsweise mit XML.load(), aber sie können nicht mit dem Internet kommunizieren.

Die Berechtigungen für Remote-SWFs unterscheiden sich nicht von Flash Player 7, mit der Ausnahme, dass Remote-SWFs nicht mehr die Berechtigung zum Laden von lokalem Inhalt haben. Remote-SWFs werden immer in einer Sandbox platziert, die der Ursprungsdomäne entspricht. Eine SWF-Datei in der Sandbox a.com kann Daten vom Server unter a.com lesen, beispielsweise mit XML.load(), und Daten an einen beliebigen Ort im Internet senden, zum Beispiel mit XML.send().

Berechtigungen für Remote-SWFs

Abbildung 7 zeigt Berechtigungen für Remote-SWFs, die zwar nicht standardmäßig verfügbar sind, aber explizit zugewiesen werden können.

Abbildung 7. Explizite Berechtigungen für Remote-SWFs

Eine SWF-Datei unter a.com kann Daten vom Server unter b.com lesen, beispielsweise mit XML.load, wenn unter b.com eine Richtliniendatei vorhanden ist, die den Zugriff von a.com oder von allen Domänen erlaubt. Eine SWF-Datei unter a.com kann ein Cross-Scripting für eine SWF-Datei unter b.com vornehmen (beispielsweise durch Aufruf einer ActionScript-Methode in der SWF-Datei unter b.com), wenn die SWF-Datei unter b.com die Funktion System.security.allowDomain("a.com") aufruft. Diese Berechtigungen waren bereits in Flash Player 7 verfügbar und haben sich in Flash Player 8 nicht geändert.

Standardmäßig können Remote-SWFs kein Cross-Scripting für lokale SWFs durchführen. SWF-Dateien in den Sandboxen Lokal mit Netzwerk und Lokal vertrauenswürdig können Remote-SWFs jedoch die Berechtigung für das Cross-Scripting erteilen, und zwar mithilfe von System.security.allowDomain(). SWF-Dateien in der Sandbox Lokal mit Dateisystem können eine derartige Berechtigung nicht erteilen, da dadurch eine Situation entstehen würde, in der eine SWF-Datei in der Sandbox Lokal mit Dateisystem und eine Remote-SWF so zusammenwirken könnten, dass Daten aus einem lokalen Dateisystem gelesen und an einen Webserver gesendet werden.

Berechtigungen für lokale vertrauenswürdige SWF-Dateien

Abbildung 8 zeigt die uneingeschränkten Berechtigungen, die lokalen vertrauenswürdigen SWF-Dateien erteilt werden. Lokale vertrauenswürdige SWF-Dateien können Daten aus lokalen Dateien lesen, mit jedem Server interagieren und ein Cross-Scripting mit jeder anderen SWF-Datei durchführen.

Abbildung 8. Berechtigungen für lokale vertrauenswürdige SWF-Dateien

Berechtigungen für SWF-Dateien in der Sandbox "Lokal mit Dateisystem"

Abbildung 9 zeigt Berechtigungen für SWF-Dateien in der Sandbox Lokal mit Dateisystem, die zwar nicht standardmäßig verfügbar sind, aber explizit zugewiesen werden können. Lokale vertrauenswürdige SWF-Dateien können mithilfe von System.security.allowDomain("*") das Cross-Scripting mit SWF-Dateien in der Sandbox Lokal mit Dateisystem zulassen.

Abbildung 9. Explizite Berechtigungen für SWF-Dateien in der Sandbox "Lokal mit Dateisystem"

Beachten Sie, dass Berechtigungen den SWF-Dateien in der Sandbox Lokal mit Dateisystem nur zugewiesen werden können, indem sie allen Domänen zugewiesen werden. Die Anforderung in Bezug auf alle Domänen entsteht dadurch, dass der Zugriff für SWF-Dateien in der Sandbox Lokal mit Dateisystem dem uneingeschränkten Zugriff entspricht, da Flash Player den Ursprung einer lokalen SWF-Datei nicht ermitteln kann.

Remote-SWFs und SWFs in der Sandbox Lokal mit Netzwerk können Dateien in der Sandbox Lokal mit Dateisystem keine Berechtigungen erteilen, da dadurch eine Situation entstehen würde, in der eine SWF-Datei in der Sandbox Lokal mit Dateisystem und eine Remote-SWF oder eine SWF in der Sandbox Lokal mit Netzwerk so zusammenwirken könnten, dass Daten aus einem lokalen Dateisystem gelesen und an einen Webserver gesendet werden.

Wenn keine expliziten Berechtigungen erteilt wurden, können SWF-Dateien in der Sandbox Lokal mit Dateisystem nur Daten aus lokalen Dateisystemen laden, beispielsweise mit XML.load().

Berechtigungen für SWF-Dateien in der Sandbox "Lokal mit Netzwerk"

Abbildung 10 zeigt die Standardberechtigungen für lokale SWF-Dateien, die sich in der Sandbox Lokal mit Netzwerk und nicht in der Sandbox Lokal mit Dateisystem befinden. Wenn keine expliziten Berechtigungen erteilt wurden, können SWF-Dateien in der Sandbox Lokal mit Netzwerk nur mit SWF-Dateien in derselben Sandbox kommunizieren und Daten an Server senden, beispielsweise mit XML.send().

Abbildung 10. Standardberechtigungen für SWF-Dateien in der Sandbox "Lokal mit Netzwerk"

Berechtigungen für SWF-Dateien in der Sandbox "Lokal mit Netzwerk"

Abbildung 11 zeigt Berechtigungen für SWF-Dateien in der Sandbox Lokal mit Netzwerk, die zwar nicht standardmäßig verfügbar sind, aber explizit zugewiesen werden können.

Abbildung 11. Explizite Berechtigungen für SWF-Dateien in der Sandbox "Lokal mit Netzwerk"

Eine SWF-Datei in der Sandbox Lokal mit Netzwerk ist berechtigt, Daten vom Server unter a.com zu lesen, beispielsweise mit XML.load(). Voraussetzung hierfür ist, dass sich unter a.com eine Richtliniendatei befindet, die den Zugriff von allen Domänen aus zulässt.

Eine SWF-Datei in der Sandbox Lokal mit Netzwerk kann ein Cross-Scripting mit einer SWF-Datei unter a.com durchführen (beispielsweise durch Aufruf einer ActionScript-Methode in der SWF-Datei unter a.com), wenn die SWF-Datei unter a.com die Funktion System.security.allowDomain("*") aufruft. Auf ähnliche Weise kann eine SWF-Datei in der Sandbox Lokal mit Netzwerk ein Cross-Scripting für eine lokale vertrauenswürdige SWF-Datei ausführen, wenn diese Datei allowDomain("*") aufruft.

Beachten Sie, dass Berechtigungen den SWF-Dateien in der Sandbox Lokal mit Netzwerk nur zugewiesen werden können, indem sie allen Domänen zugewiesen werden. Die Anforderung in Bezug auf alle Domänen entsteht dadurch, dass der Zugriff für SWF-Dateien in der Sandbox Lokal mit Netzwerk dem uneingeschränkten Zugriff entspricht, da Flash Player den Ursprung einer lokalen SWF-Datei nicht ermitteln kann.

Es ist keine Berechtigung verfügbar, die einer SWF-Datei in der Sandbox Lokal mit Netzwerk das Lesen aus lokalen Dateien ermöglicht.

Übersicht über den Datenfluss

Abbildung 12 zeigt, welche Datenflüsse möglich sind, wenn die maximale Berechtigungsmenge vorhanden ist.

Abbildung 12. Übersicht über den Datenfluss

Mithilfe von Berechtigungen kann eine vollständige Interoperabilität zwischen SWF-Dateien in der Sandbox Lokal mit Netzwerk und Remote-SWFs sowie Servern erzielt werden. Außerdem können lokale vertrauenswürdige SWF-Dateien über Berechtigungen frei mit Netzwerkressourcen kommunizieren und umgekehrt.

Doch selbst wenn die maximale Berechtigungsmenge eingestellt wurde, ist ein Datenfluss von lokalen Dateisystemen zum Internet nur über den Umweg einer lokalen vertrauenswürdigen SWF-Datei möglich.

Flash Player-Einbettung und lokale Sicherheit

Sie können lokale Anwendungen erstellen, die Flash Player als Komponente in einer eigenen Benutzeroberfläche einbetten. Dies gilt nur für native lokale Anwendungen, die als ausführbare Programme erstellt werden.

Macromedia erlaubt diesen Einsatz von Flash Player, bietet jedoch keinen technischen Support. Die Integration von Flash Player in einer Anwendung ist risikobehaftet, da Sie Flash Player nicht zusammen mit Ihrer Anwendung verteilen können, so dass die auf dem Computer des Benutzers installierte Flash Player-Version verwendet werden muss. Wenn Benutzer einen Upgrade von Flash Player durchführen, kann sich das Verhalten Ihrer Anwendung auf unerwartete Weise ändern.

Dennoch ist Macromedia bemüht, Probleme bei Anwendungen, in denen Flash Player eingebettet ist, weitgehend auszuschließen.

In Flash Player 8 und höheren Versionen gilt beim Einbetten das folgende Verhalten in Bezug auf die lokale Sicherheit:

Wenn das ActiveX-Steuerelement von Flash Player erkennt, dass es sich in einem Container befindet, der kein Browser ist, deaktiviert es die neuen Regeln für die lokale Sicherheit und platziert alle lokalen SWF-Dateien in der lokalen vertrauenswürdigen Sandbox. Dies ist auch dann der Fall, wenn das ActiveX-Steuerelement innerhalb einer Instanz des ActiveX-Steuerelements von Internet Explorer instanziiert ist, welches sich wiederum in einem Container befindet, der kein Browser ist. Beachten Sie, dass hierbei nur die letzte Containeranwendung von Bedeutung ist. Wenn das ActiveX-Steuerelement von Flash Player also in einem anderen ActiveX-Steuerelement eingebettet ist, das wiederum in Internet Explorer eingebettet ist, erkennt der Flash Player, dass er in einem Browser ausgeführt wird, und aktiviert die lokale Sicherheit.
Flash Player-Plug-Ins erkennen nicht, ob ihr Container ein Browser ist oder nicht. Deshalb sind die Regeln für die lokale Sicherheit bei Plug-Ins immer aktiviert. Aber wenn Endbenutzer (mit dem Einstellungsmanager) oder Installationsprogramme (mit FlashPlayerTrust-Konfigurationsdateien) den Pfad einer ausführbaren Anwendung, in der ein Flash Player-Plug-In eingebettet ist, als vertrauenswürdig einstufen, deaktiviert das Plug-In die neuen Regeln für die lokale Sicherheit, wenn es innerhalb des ausführbaren Programms eingebettet ist.
ActiveX- und Plug-In-Player verfügen über exportierte APIs, über die Hostanwendungen bestimmen können, ob die neuen Regeln für die lokale Sicherheit erzwungen werden oder nicht. Diese APIs müssen zu einem frühen Zeitpunkt des Flash Player-Lebenszyklus aufgerufen werden, und zwar vor dem Laden von Inhalt. Dies sind die folgenden APIs:

        ActiveX (IDispatch APIs):
HRESULT IShockWaveFlash::EnforceLocalSecurity() 
HRESULT IShockWaveFlash::DisableLocalSecurity()

    

        Plugins (DLL exports):
NPError Flash_EnforceLocalSecurity() 
NPError Flash_DisableLocalSecurity()

    

Bei der Entwicklung einer lokalen Anwendung, in der Flash Player eingebettet ist, sollten Sie explizit angeben, ob die Regeln für die lokale Sicherheit aktiviert oder deaktiviert sein sollen und dazu die entsprechende API aufrufen. Im Allgemeinen empfiehlt es sich, die Regeln für die lokale Sicherheit zu aktivieren, wenn bei der Verwendung von Flash Player SWF-Inhalt aus Quellen wiedergegeben wird, die nicht Ihrer Kontrolle unterstehen, wie beispielsweise aus dem Internet. Wenn dagegen nur bestimmte SWF-Dateien wiedergegeben werden, die Sie erstellen und mit Ihrer Anwendung ausliefern, kann es praktisch sein, die lokale Sicherheit zu deaktivieren, um ein Höchstmaß an Flexibilität zu erzielen.

Speichern des Inhalts von Drittanbietern

Flash Player ab Version 8 bietet Benutzern eine Möglichkeit, die der Option ähnelt, die zahlreiche Browser für die Cookies von Dritten anbieten: Benutzer können das Lesen und Schreiben von im Client permanent vorhandenen gemeinsamen Objekten durch SWF-Dateien aus anderen Domänen deaktivieren. Standardmäßig ist das Speichern des Inhalts von Dritten aktiviert. Sie können diese Option jedoch deaktivieren, indem Sie im Einstellungsmanager von Flash Player das Kontrollkästchen Zulassen, dass Flash-Inhalte Daten von Drittanbietern auf dem Computer speichern deaktivieren. Eine SWF-Datei von Drittanbietern ist jede SWF, deren Ursprungsdomäne nicht mit der primären Domäne übereinstimmt, die der Benutzer besucht und die in der Adressleiste des Browsers angezeigt wird.

Die Option zum Speichern des Inhalts von Drittanbietern betrifft sowohl lokale gemeinsame Objekte als auch die weniger bekannten permanenten gemeinsamen Remote-Objekte, die nur in Verbindung mit Flash Media Server früher Flash Communication Server verwendet werden.

Wenn das Speichern des Inhalts von Drittanbietern deaktiviert ist und eine SWF-Datei versucht, ein gemeinsames Objekt über SharedObject.getLocal oder SharedObject.getRemote abzurufen, bestimmt Flash Player, ob die aufrufende SWF-Datei von einem Drittanbieter stammt oder nicht. Dazu vergleicht Flash Player die Ursprungsdomäne der SWF-Datei mit der Domäne, die in der Adressleiste des Browsers angezeigt wird. Wenn die beiden Domänen nicht genau übereinstimmen, wird die SWF-Datei als Inhalt von Drittanbietern klassifiziert. In diesem Fall gibt der Aufruf von getLocal oder getRemote den Wert null zurück.

Die Einschränkung in Bezug auf den Inhalt von Drittanbietern betrifft ausschließlich Remote-SWFs, nicht aber lokale SWF-Dateien, die vom Dateisystem der Benutzer geladen werden. Da zur Klassifizierung als Inhalt von Drittanbietern ein Vergleich mit einer Browser-URL durchgeführt werden muss, berücksichtigt Flash Player diese Einschränkung nur bei der Wiedergabe von Inhalt in einem Webbrowser. Bei eigenständigen Playern, Flash-Authoring-Playern und Projektoren spielt diese Einschränkung dagegen keine Rolle.

Wenn Sie betroffen sind

Wenn Ihre SWF-Datei tatsächlich von Drittanbietern stammt, also in die Website eines anderen Anbieters integriert ist, lässt sich nicht vermeiden, dass einige Benutzer es Ihrer SWF-Datei nicht gestatten werden, gemeinsame Objekte zu lesen oder zu schreiben. Die Gründe hierfür werden im nächsten Abschnitt beschrieben.

Wenn Ihre SWF-Datei als Inhalt von Drittanbietern gilt, aber nur innerhalb von Sites verwendet wird, die Ihrer Kontrolle unterstehen, müssen Sie Ihre Site möglicherweise so umgestalten, dass SWF-Dateien, die permanente gemeinsame Objekte lesen oder schreiben müssen, immer von der primären Domäne bereitgestellt werden, die der Benutzer besucht.

Welchen Grund haben die Einschränkungen in Bezug auf den Inhalt von Drittanbietern?

Beim Surfen im Internet muss stets ein Kompromiss zwischen Datenschutz und Komfort gefunden werden. Es ist meist unvermeidbar, dass Benutzer bestimmte Informationen preisgeben müssen, wie ihre IP-Adressen sowie Betriebssystem und Browser, doch allgemein möchten die meisten Benutzer persönliche Daten geheim halten oder nur bekannten, vertrauenswürdigen Dritten zur Verfügung stellen. Ein Aspekt der Benutzerprofile, der in letzter Zeit in den Blickpunkt gerückt ist, ist der Surfverlauf, der von Webinhalten gespeichert wird. Wenn zahlreiche Sites die Besuche der Benutzer auf ähnliche Weise protokollieren und die aufgezeichneten Daten später wieder lesen können, lässt sich ein Muster des Surfverhaltens ablesen, was von zahlreichen Benutzern und Datenschutzbeauftragten als Verletzung der Privatsphäre empfunden wird.

Im Allgemeinen können solche Daten an zwei Orten gespeichert werden: auf Webservern und auf den Computern der Benutzer. Client-Technologien wie Webbrowser und Flash Player haben keinen Einfluss auf Webserver, so dass interessierte Dritte mithilfe von Webservern Daten zum Surfverhalten der Benutzer erfassen können. Das Speichern von solchen Daten auf Servern hat jedoch einige deutliche Nachteile: Speicherplatz und die Kommunikation zwischen Servern sind erforderlich und können mit hohen Kosten verbunden sein. Zudem kann es schwierig sein, einen Benutzer bei mehreren Besuchen eindeutig zu identifizieren, da Identitätskennzeichen wie IP-Adressen sich im Lauf der Zeit ändern oder auch von mehreren Benutzern gemeinsam genutzt werden können. Deshalb ist die bevorzugte Methode zur Aufzeichnung des Surfverhaltens das Speichern von Daten auf den Computern der Benutzer. Dabei entsteht ein Protokoll der Sites, die von einem bestimmten Computer aus besucht wurden.

Zwei Technologien, die zu diesem Zweck verwendet werden, sind Browser-Cookies und permanente gemeinsame Objekte in Flash. Browser und Flash Player implementieren eine ursprungsspezifische Sicherheitsrichtlinie, die verhindert, dass Sites Cookies oder gemeinsame Objekte lesen können, die von anderen Sites erstellt wurden. Aufgrund dieser Einschränkung reicht es für beteiligte Sites nicht aus, Browseraufzeichnungen im eigenen Datenspeicher zu speichern; andere Sites könnten diese Informationen nicht lesen, um Verlaufsdaten zu erstellen. Stattdessen wird häufig eine bestimmte Domäne zum Aufzeichnen aller Verlaufsinformationen vorgesehen, wobei jede beteiligte Site anschließend ein Dokument, das Verlaufsdaten schreibt, von dieser Domäne referenziert. Die Informationen zur Identifikation der Site werden dabei in der URL übergeben, die zum Abrufen des Dokuments verwendet wird. Bei späteren Besuchen kann ein Dokument der gemeinsamen Domäne, das Verlaufsdaten liest, auf alle Daten zugreifen, die in dem Dokument vorhanden sind, das Cookies schreibt. So wird ein Teil des Surfverhaltens des Benutzers offen gelegt.

In Webbrowsern und Flash Player können Benutzer nun steuern, wie ihr Surfverhalten mit dieser Technik aufgezeichnet werden kann. Browser und Flash Player geben Benutzern die Möglichkeit, das Lesen und Schreiben von permanenten Daten von Dritten zu deaktivieren. In diesem Zusammenhang ist ein Drittanbieter jede Domäne, die nicht mit der primären Domäne übereinstimmt, die der Benutzer besucht und die in der Adressleiste des Browsers angezeigt wird. Folgendes Beispiel soll dies veranschaulichen: Ein Benutzer hat das Speichern des Inhalts von Drittanbietern deaktiviert und besucht http://site1.com/index.html. Die Datei index.html enthält http://common.com/writeHistory.html?domain=site1.com, und die Datei writeHistory.html versucht, permanente Daten zu lesen oder zu schreiben. Weder der Browser noch Flash Player lassen dies zu, da common.com die Domäne eines Dritten ist; der Benutzer zeigt site1.com im Browser an, nicht common.com.

Standardwert für allowScriptAccess

Flash Player bietet ab Version 6 Unterstützung für einen HTML-Parameter namens allowScriptAccess. Dieser Parameter steuert, ob der ActionScript-Code in einer SWF-Datei den JavaScript-Code in der übergeordneten HTML-Seite aufrufen darf. Der umgekehrte Fall, wobei JavaScript den ActionScript-Code aufruft, wird von System.security.allowDomain gesteuert.

Für allowScriptAccess sind folgende Werte möglich:

always: Aufrufe von ActionScript an JavaScript sind immer zulässig
sameDomain: Aufrufe von ActionScript an JavaScript sind nur zulässig, wenn die SWF-Datei und die HTML-Seite aus derselben Domäne stammen
never: Aufrufe von ActionScript an JavaScript sind nie zulässig

In Flash Player 6 und 7 hatte allowScriptAccess den Standardwert always wenn nicht von der HTML-Seite angegeben . Getrennt davon war der Standardwert für allowScriptAccess in den HTML-Veröffentlichungsvorlagen von Flash immer sameDomain. Wenn Sie die Ausgabe der HTML-Veröffentlichung in Flash unverändert lassen, tritt das Verhalten sameDomain auf, da die HTML-Seite Flash Player gegenüber sameDomain angibt.

Wenn für allowScriptAccess kein Wert angegeben wird, ist der Standardwert in Flash Player 8 auch weiterhin always, sofern es sich bei der SWF-Hauptdatei in Flash Player um Version 7 oder eine frühere Version handelt. Bei einer SWF-Hauptdatei ab Version 8 lautet der Standardwert dagegen sameDomain.

Der Parameter allowScriptAccess lässt Flash-Inhalt in einer HTML-Seite zu, verhindert aber, dass Skripts in der HTML-Seite ausgeführt werden. Dies kann nützlich sein, wenn in der HTML-Seite Flash-Inhalt verwendet wird, der nicht als vertrauenswürdig betrachtet wird. Wenn Sie beispielsweise ein Forum anbieten, in dem Benutzer eigene SWF-Signaturen angeben können und der generierte HTML-Code diese SWFs direkt als Quelle heranzieht, sollen die SWFs vermutlich nicht berechtigt sein, Skripts in Ihren HTML-Seiten auszuführen.

Im folgenden Beispiel wird gezeigt, wie allowScriptAccess angegeben wird:

        <object
     classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
     codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0"
     width="375" height="300">
   <param name="movie" value="hello.swf">
   <param name="allowScriptAccess" value="sameDomain">
   <embed
       pluginspage="http://www.macromedia.com/go/getflashplayer"
       type="application/x-shockwave-flash"
       src="hello.swf"
       width="375" height="300"
       allowScriptAccess="sameDomain">
 </object>
          
    

Platzhalterzeichen für allowDomain

Hinweis: Die in diesem Abschnitt beschriebenen Änderungen gelten sowohl für System.security.allowDomain() als auch für System.security.allowInsecureDomain(). Der Übersichtlichkeit wegen wird nur System.security.allowDomain behandelt; die Änderungen an System.security.allowInsecureDomain() sind identisch. Der Aufruf von System.security.allowInsecureDomain() wird nicht empfohlen, da dies die über SSL (HTTPS) erzielte Sicherheit beeinträchtigt.

Ab Flash Player 8 kann mit System.security.allowDomain() ein Sternchen (*) als Platzhalterzeichen verwendet werden. Der Aufruf von System.security.allowDomain("*") ermöglicht anderen SWF-Dateien aus allen Domänen den Scripting-Zugriff, also nicht nur SWFs aus einer bestimmten Domäne.

Das Platzhalterzeichen ist praktisch, wenn Sie Daten offen mit anderen Domänen austauschen möchten und dabei keine vertraulichen Daten geschützt werden müssen. Vor dem Aufruf von System.security.allowDomain("*") müssen Sie jedoch sicherstellen, dass die aufrufende SWF-Datei keine vertraulichen Informationen oder ActionScript-Codefragmente enthält. Nach einem Aufruf von System.security.allowDomain("*") können SWF-Dateien aus jedem Ort im Internet Ihre SWF-Datei laden und zum Scripting verwenden – also auch SWF-Dateien, die zu bösartigen Zwecken geschrieben wurden.

In manchen Fällen müssen Sie System.security.allowDomain() aufrufen, obwohl die Domäne, von der die kooperierende SWF-Datei bereitgestellt wird, erst zur Laufzeit bekannt ist. Dies kann der Fall sein, wenn die kooperierende SWF-Datei von einem Lastausgleich-Cluster bereitgestellt wird oder wenn Ihre SWF-Datei in vielen verschiedenen Domänen verwendet wird. In einer solchen Situation darf System.security.allowDomain("*") nicht ohne besondere Vorsichtsmaßnahmen aufgerufen werden, da Ihre SWF-Datei sonst von jeder anderen SWF-Datei im Internet zum Scripting verwendet werden kann. Warten Sie stattdessen, bis die kooperierende SWF-Datei geladen wurde, und ermitteln Sie dann ihre Domäne mit der ActionScript-Eigenschaft MovieClip._url. Nachdem Sie den Wert der Eigenschaft _url an System.security.allowDomain() übergeben haben, sollte die SWF-Datei im referenzierten Movieclip in der Lage sein, die SWF-Datei zum Scripting zu verwenden, die System.security.allowDomain() aufgerufen hat.

In Flash Player 8 sind SWF-Dateien jeder Version berechtigt, das Platzhalterzeichen "*" an System.security.allowDomain() zu übergeben. Wenn Sie jedoch System.security.allowDomain("*") in einer SWF-Datei vor Version 8 aufrufen, sollten Sie zuvor sicherstellen, dass der Player mindestens die Version 8 hat (System.capabilities.version), da frühere Versionen von Flash Player das Platzhalterzeichen "*" nicht als Argument für System.security.allowDomain erkennen.

Genauere Berechtigungen

Beim Aufruf von System.security.allowDomain() sind zwei Komponenten an der so entstandenen Berechtigung beteiligt: die gewährende Komponente, also die SWF-Datei, die System.security.allowDomain() aufruft, und die verwendende Komponente, also die Domäne, die im Argument für System.security.allowDomain() angegeben ist. Nachdem diese Berechtigung eingerichtet wurde, kann jede SWF-Datei aus der verwendenden Domäne die gewährende SWF-Datei zum Scripting heranziehen.

In Flash Player 6 und 7 konnte jede SWF-Datei aus der verwendenden Domäne nicht nur die gewährende SWF-Datei selbst zum Scripting heranziehen, sondern auch jede SWF-Datei aus der Domäne der gewährenden SWF-Datei. Die gewährende Komponente wurde also nicht als gewährende SWF, sondern als gewährende Domäne betrachtet. Wenn beispielsweise eine SWF-Datei aus http://site1.com/app1.swf die Funktion System.security.allowDomain("site2.com") aufgerufen hat, konnte eine SWF-Datei aus http://site2.com/another.swf entweder die gewährende SWF aus http://site1.com/app1.swf zum Scripting heranziehen oder jede andere SWF-Datei, die von site1.com geladen wurde, wie beispielsweise http://site1.com/different.swf.

Dabei konnten in manchen Fällen unerwartete Ergebnisse auftreten. Beispielsweise ist der Verwalter von site1.com für viele verschiedene Flash-Anwendungen zuständig, die nichts miteinander zu tun haben. Möglicherweise müssen einige der Anwendungen in site1.com, aber nicht alle, einer externen Domäne Zugriff gewähren. Der Autor von app1.swf weiß dies eventuell nicht und erteilt durch Aufruf von System.security.allowDomain("site2.com") nicht nur app1.swf, sondern auch anderen SWFs den Zugriff.

Wenn eine SWF-Datei ab Version 8 System.security.allowDomain() aufruft, ist die aufrufende SWF-Datei die einzige gewährende Komponente. Wenn zwei verschiedene SWF-Dateien aus derselben Domäne einer externen Domäne den Zugriff erteilen möchten, müssen beide SWF-Dateien System.security.allowDomain() aufrufen.

Dieses Verhalten gilt nur für SWF-Dateien ab Version 8. SWF-Dateien der Version 6 und 7, die System.security.allowDomain() aufrufen, erteilen den Zugriff allen SWF-Dateien der Version 6 und 7 in ihrer eigenen Domäne, um die Abwärtskompatibilität zu gewährleisten (auch bei der Wiedergabe in Flash Player 8). Aber wenn eine SWF-Datei der Version 6 oder 7 System.security.allowDomain() aufruft, erhalten SWF-Dateien ab Version 8 in der eigenen Domäne keinen Zugriff.

Dieselbe verhaltensspezifische Änderung wurde auch für System.exactSettings vorgenommen. Diese Funktion bestimmt, ob eine SWF-Datei die Flash 6-Superdomäne (beispielsweise ist mysite.com die Superdomäne von www.mysite.com) oder die genaue Flash 7-Domäne (wie zum Beispiel www.mysite.com) als Grundlage für Kamera- und Mikrofonberechtigungen und permanente gemeinsame Objekte verwendet. Wenn eine SWF-Datei in einer Domäne in Flash Player 7 den Wert von System.exactSettings ändert, gilt diese Änderung für alle SWF-Dateien aus derselben Domäne. Bei SWF-Dateien ab Version 8 betrifft die Einstellung von System.exactSettings nur die aufrufende SWF-Datei.

Sichere permanente gemeinsame Objekte

In Flash Player ab Version 8 kann eine SWF-Datei, die von einer HTTPS-URL stammt, beim Lesen oder Schreiben eines permanenten gemeinsamen Objekts angeben, ob ein separater Speicher für gemeinsame Objekte verwendet werden soll, der nur SWF-Dateien zur Verfügung steht, die über HTTPS bereitgestellt werden. Solche gemeinsamen Objekte sind immun gegen die unten beschriebenen hypothetischen Angriffe. Abgesehen von der HTTPS-Anforderung sind die Regeln für den Zugriff auf gemeinsame Objekte im sicheren Speicher mit den Regeln für nicht sichere gemeinsame Objekte identisch: Standardmäßig kann nur eine SWF-Datei aus derselben URL wie der ursprüngliche Ersteller auf das gemeinsame Objekt zugreifen. Wenn der Ersteller jedoch eine Option localPath angegeben hat, die kürzer als die vollständige URL ist, können auch andere SWFs, deren URL mit demselben Präfix beginnt, auf das gemeinsame Objekt zugreifen, indem sie denselben localPath angeben.

Sichere gemeinsame Objekte abrufen

Zum Abrufen eines sicheren gemeinsamen Objekts muss der Wert true für den neuen, optionalen Parameter secure an SharedObject.getLocal() oder SharedObject.getRemote() übergeben werden:

        static function getLocal(name:String, localPath:String, secure:Boolean) : SharedObject;
static function getRemote(name:String, remotePath:String, persistence:Object, secure:Boolean) : SharedObject;

(Beachten Sie, dass gemeinsame Remote-Objekte Flash Media Server erfordern und nur in der Dokumentation dieses Produkts beschrieben werden.)

Beispielsweise kann ein sicheres lokales gemeinsames Objekt folgendermaßen abgerufen werden:

var mySO = SharedObject.getLocal("userInfo", null, true);

(Der Wert null für localPath hat dieselbe Wirkung wie das Weglassen von localPath. Übergeben Sie deshalb null für localPath, wenn ein sicheres gemeinsames Objekt mit dem Standardwert für localPath gewünscht wird.)

Das Flag secure hat den Standardwert false. Deshalb sind SWF-Dateien, die mit einer älteren Version als Flash Player 8 erstellt wurden, nicht von diesem neuen Funktionsmerkmal betroffen. Der neue, separate sichere Speicher wird nur für SWF-Dateien verwendet, die sichere gemeinsame Objekte konkret anfordern. Alle gemeinsamen Objekte, die von älteren SWFs erstellt wurden, befinden sich im ursprünglichen nicht sicheren Speicher. Dabei spielt es keine Rolle, ob HTTPS verwendet wird oder nicht.

Wenn eine SWF-Datei, die nicht von einer HTTPS-URL stammt, für den Parameter secure den Wert true übergibt, gibt der Aufruf von getLocal() oder getRemote() den Wert null zurück.

Sichere und nicht sichere gemeinsame Objekte stammen aus separaten Speichern. Deshalb können zwei permanente gemeinsame Objekte (ein sicheres und ein nicht sicheres) abgerufen werden, deren Namen, localPaths und Domänen identisch sind, die aber dennoch separate Objekte sind. Wenn beispielsweise eine HTTPS-SWF ein sicheres gemeinsames Objekt namens "userInfo" mit dem localPath "/" erstellt und eine HTTP-SWF später ein nicht sicheres gemeinsames Objekt namens "userInfo" mit dem localPath "/" abruft, handelt es sich um zwei separate Objekte, die aus unterschiedlichen Speichern stammen.

Gründe für die Verwendung von sicheren gemeinsamen Objekten

Sichere permanente gemeinsame Objekte bieten Schutz vor hypothetischen Angriffen nicht autorisierter Parteien auf vertrauliche Daten.

Das HTTPS-Protokoll zeichnet sich durch mehrere wichtige Schutzmechanismen aus. Der bekannteste dieser Mechanismen ist die Verschlüsselung, die verhindert, dass unbefugte Dritte im Netzwerk den Inhalt der Netzwerkkommunikation sehen können. Ein weiterer wichtiger Aspekt ist die Integrität. Dadurch wird gewährleistet, dass die gesendeten Daten entweder unverändert beim Empfänger ankommen oder dass im Falle von geänderten Daten die Änderungen erkannt und die Daten als ungültig zurückgewiesen werden. Dadurch werden so genannte Man-in-the-Middle-Angriffe vereitelt, die sich die verteilte Architektur des Internets zunutze machen: Eine Partei in der Mitte der Netzwerkkommunikation (wie ein Mitarbeiter eines ISP, ein Netzwerkbetreiber, Proxyserver oder eine Firewall) kann nicht nur die Kommunikation überwachen, sondern auch die in beide Richtungen gesendeten Daten modifizieren und beispielsweise ein eigenes Dokument einfügen, das im Auftrag des Senders Aktionen ausführt, die der Sender nicht beabsichtigt hat. Angenommen, ein Benutzer besucht die Website beispiel.com und zeigt eine SWF-Datei an, auf der er zur Eingabe von Anmeldedaten aufgefordert wird. In diesem Fall könnte ein Man-in-the-Middle-Angreifer die SWF-Datei durch eine eigene, fast identische SWF-Datei ersetzen, die die Anmeldedaten nicht nur an den vorgesehenen Empfänger, sondern auch an den Angreifer sendet. Bei einer sicheren HTTPS-Verbindung würde die geänderte SWF-Datei des Angreifers jedoch beim Empfänger abgelehnt, so dass der Angriff zum Scheitern verurteilt ist.

Bei einer ähnlichen Angriffsform werden DNS-Schwachstellen oder andere Sicherheitslücken in Systemen ausgenutzt, die zur Identifizierung eines Servers dienen, um eine Identitätsfälschung der Site zu bewirken, die eine SWF-Datei bereitstellt. Eine HTTPS-Eigenschaft namens Authentifizierung kann derartige Angriffe verhindern, indem die Identität des Servers mithilfe von SSL-Zertifikaten überprüft wird. Für unsere Zwecke genügt es, Man-in-the-Middle-Angriffe genauer zu beschreiben und dabei auch Probleme in Bezug auf die Identitätsfälschung abzudecken.

Wenn Sie eine SWF-Datei über HTTPS bereitstellen und ein permanentes gemeinsames Objekt von dieser SWF schreiben, sollen die Daten im gemeinsamen Objekt möglicherweise nur Ihren eigenen SWF-Dateien und dem Benutzer zur Verfügung stehen. Dies ist beispielsweise der Fall, wenn im permanenten gemeinsamen Objekt vertrauliche Daten aufgezeichnet werden, wie Konto- oder Bankinformationen. Im Idealfall möchten Sie sicherstellen, dass Angreifer nicht auf die Daten im gemeinsamen Objekt zugreifen können, sollte ein Benutzer Opfer eines Man-in-the-Middle-Angriffs werden.

Wenn Ihre HTTPS-SWF in Flash Player 7 ein gemeinsames Objekt schreibt und ein Benutzer anschließend Opfer eines Man-in-the-Middle-Angriffs wird und deshalb dazu verleitet wird, eine URL Ihrer Site aufzurufen, von der der Zugriff auf das gemeinsame Objekt möglich ist (eventuell sogar dieselbe URL, von der die SWF-Datei bereitgestellt wird), wobei jedoch HTTP anstelle von HTTPS verwendet wird, könnte der Angreifer seine eigene SWF-Datei senden. In diesem Fall würde Flash Player annehmen, dass die SWF-Datei des Angreifers von Ihrer eigenen Site stammt. Die SWF-Datei des Angreifers könnte dann das gemeinsame Objekt lesen und den Inhalt an den Angreifer senden.

Angriffe dieser Art lassen sich nur schwer durchführen. Wenn Sie bereits HTTPS-SWFs bereitgestellt haben, die vertrauliche Daten in permanente gemeinsame Objekte geschrieben haben, ist es relativ unwahrscheinlich, dass Unbefugte mit dieser Angriffsform versucht haben, auf Ihre Daten zuzugreifen. Dennoch empfiehlt es sich, vertrauliche Daten in Zukunft in sicheren gemeinsamen Objekten aufzubewahren, um ein Höchstmaß an Sicherheit zu erzielen.

Weitere Schritte

Flash Player ist heute eines der am häufigsten eingesetzten Softwareprogramme der Welt. Dieser Erfolg ist auf die Rich-Media-Funktionen, die Stabilität und die Zuverlässigkeit des Produkts zurückzuführen. Flash Player 8 kann nicht nur mit ausdrucksstarken Funktionen und höherer Leistung aufwarten, sondern bietet Millionen von Benutzern auch verbesserten Schutz beim Surfen im Internet. Deshalb wird Flash Player auch in Zukunft von Sicherheitsexperten als zuverlässige Software geschätzt werden, die Benutzern die Kontrolle über persönliche Daten ermöglicht.

Die in diesem Artikel beschriebenen Verbesserungen gehen zwangsweise mit gewissen Nebeneffekten einher. Ein Bruchteil der Millionen von SWF-Dateien, die weltweit im Einsatz sind, wird von den neuen Schutzmaßnahmen in einer Weise betroffen sein, die unbeabsichtigt ist und sich nicht prognostizieren ließ. Macromedia nimmt solche Sicherheitsänderungen und Entwicklungen nur nach reiflicher Überlegung und sorgfältiger Abwägung der Vor- und Nachteile vor. Die Flash-Technologie genießt heute den Ruf, dass nach der erstmaligen Implementierung ein reibungsloser Betrieb gewährleistet ist. Selbst alter Flash-Inhalt kann in neueren Flash Player-Versionen genauso gut wiedergegeben werden wie bei der Veröffentlichung. Macromedia nimmt seine Verantwortung gegenüber Flash Player-Benutzern sehr ernst. Durch die hohe Sicherheit und Zuverlässigkeit von Flash Player gewährleisten wir eine stabile Zukunft für Rich Media.

Flash User Forum

04/23/2012	Auto-Save and Auto-Recovery
04/23/2012	Open hyperlinks in new window/tab/pop-up ?
04/21/2012	PNG transparencies glitched
04/01/2010	Workaround for JSFL shape selection bug?

Flash Cookbooks

02/13/2012	Randomize an array
02/11/2012	How to create a Facebook fan page with Flash
02/08/2012	Digital Clock
01/18/2012	Recording webcam video & audio in a flv file on local drive

AdAuswahl