Legt fest, wie in Flash Player die für bestimmte Flash Player-Einstellungen, beispielsweise Berechtigungen für Kamera und Mikrofon, Speicheranteile oder Speicher für permanente gemeinsame Objekte, zu verwendende Domäne ausgewählt wird. Sie können exactSettings auf false setzen, damit die SWF-Datei die gleichen Einstellungen verwendet, die in Flash Player 6 verwendet wurden.

In Flash Player 6 basiert die für diese Player-Einstellungen verwendete Domäne auf dem der Domäne der SWF-Datei nachgestellten Teil. Wenn die Domäne einer SWF-Datei mehr als zwei Segmente enthält, beispielsweise www.example.com, wird das erste Segment der Domäne ("www") entfernt und der restliche Teil der Domäne verwendet, d. h. example.com. In Flash Player 6 wird daher bei www.example.com und bei store.example.com die Domäne example.com als Domäne für diese Einstellungen verwendet. Genauso wird bei www.example.co.uk und store.example.co.uk die Domäne example.co.uk als Domäne für diese Einstellungen verwendet. In Flash Player 7 und späteren Versionen werden Player-Einstellungen in der Standardeinstellung entsprechend der exakten Domäne einer SWF-Datei ausgewählt. Beispiel: Eine SWF-Datei von www.example.com verwendet die Player-Einstellungen für www.example.com und eine SWF-Datei von store.example.com für store.example.com.

Wenn Security.exactSettings auf true gesetzt ist, verwendet Flash Player exakte Domänen für Player-Einstellungen. Wenn es auf false gesetzt ist, werden die in Flash Player 6 verwendeten Domäneneinstellungen verwendet. Der Standardwert für exactSettings lautet true. Wenn Sie den Standardwert von exactSettings ändern, muss dies vor dem Eintreten von Ereignissen erfolgen, bei denen Flash Player Player-Einstellungen auswählen muss, beispielsweise beim Verwenden einer Kamera oder eines Mikrofons oder beim Abrufen eines permanenten gemeinsamen Objekts.

Wenn Sie zuvor eine SWF-Datei der Version 6 veröffentlicht und über diese permanente gemeinsame Objekte erstellt haben und nun die permanenten gemeinsamen Objekte von dieser SWF-Datei abrufen möchten, nachdem diese in Version 7 oder eine spätere Version übertragen wurde, oder von einer anderen SWF-Datei ab Version 7 abrufen möchten, setzen Sie Security.exactSettings auf false, bevor Sie SharedObject.getLocal() aufrufen.

Siehe auch

Gibt den Typ der Sicherheits-Sandbox an, in der die aufrufende SWF-Datei verwendet wird.

Security.sandboxType weist einen der folgenden Werte auf:

• remote (Security.REMOTE): Die SWF-Datei stammt von einer Internet-URL und kann entsprechend den domänenbasierten Sandbox-Regeln verwendet werden.
• localWithFile ( Security.LOCAL_WITH_FILE): Die SWF-Datei ist eine lokale Datei, die für den Benutzer nicht vertrauenswürdig ist und nicht für die Verwendung im Netzwerk veröffentlicht wurde. Die SWF-Datei kann lokale Datenquellen lesen, jedoch keine Verbindung mit dem Internet herstellen.
• localWithNetwork (Security.LOCAL_WITH_NETWORK): Die SWF-Datei ist eine lokale Datei, die für den Benutzer nicht vertrauenswürdig ist und für die Verwendung im Netzwerk veröffentlicht wurde. Die SWF-Datei kann eine Verbindung mit dem Internet herstellen, jedoch keine lokalen Datenquellen lesen.
• localTrusted (Security.LOCAL_TRUSTED): Die SWF-Datei ist eine lokale Datei, die für den Benutzer über den Einstellungsmanager oder eine FlashPlayerTrust-Konfigurationsdatei als vertrauenswürdig gekennzeichnet wurde. Die SWF-Datei kann lokale Datenquellen lesen und eine Verbindung mit dem Internet herstellen.

Diese Eigenschaft kann in einer SWF-Datei jeder beliebigen Flash-Version verwendet werden, wird jedoch nur in Flash Player 8 oder späteren Versionen unterstützt. Das bedeutet, dass Sie diese Eigenschaft beispielsweise von einer SWF-Datei mit Version 7, die in Flash Player 8 wiedergegeben wird, aus untersuchen können. Diese Unterstützung aller Versionen bedeutet, dass Sie bei einer Veröffentlichung für eine ältere Version als 8 zum Zeitpunkt der Veröffentlichung nicht wissen, ob diese Eigenschaft bei der Wiedergabe unterstützt wird. Daher hat diese Eigenschaft in SWF-Dateien bis einschließlich Version 7 einen nicht definierten Wert. Dies sollte jedoch nur dann der Fall sein, wenn es sich bei der Player-Version (angegeben durch flash.system.Capabilities.version) um eine Version vor Version 8 handelt. In diesem Fall können Sie den Sandbox-Typ danach ermitteln, ob es sich bei der SWF-Datei um eine lokale Datei handelt. Wenn es sich um eine lokale Datei handelt, wird die SWF-Datei in Flash Player als localTrusted klassifiziert. (In den Versionen vor Flash Player 8 wurden alle lokalen Inhalte auf diese Weise klassifiziert.) Wenn es sich nicht um eine lokale Datei handelt, wird die SWF-Datei in Flash Player als remote klassifiziert.

Weitere Informationen finden Sie in den folgenden Abschnitten:

• Das Kapitel Sicherheit im Handbuch Programmieren mit ActionScript 3.0 und die neusten Kommentare zu den LiveDocs.
• Das Flash Player 9-Whitepaper zum Thema Sicherheit

Siehe auch

Hiermit können SWF- und HTML-Dateien der angegebenen Domänen auf Objekte und Variablen in der SWF-Datei zugreifen, die den Aufruf allowDomain() enthält.

Wenn zwei SWF-Dateien von derselben Domäne aus bereitgestellt werden, z. B. von http://mysite.com/swfA.swf und http://mysite.com/swfB.swf, kann swfA.swf Variablen, Objekte, Eigenschaften, Methoden usw. in swfB.swf untersuchen und ändern, und swfB.swf kann dasselbe bei swfA.swf tun. Dies wird als Skripterstellung über mehrere Filme oder Cross-Scripting bezeichnet.

Wenn zwei SWF-Dateien über verschiedene Domänen bereitgestellt werden, beispielsweise http://siteA.com/swfA.swf und http://siteB.com/siteB.swf, kann swfA.swf in Flash Player keine Skripterstellung von swfB.swf durchführen und umgekehrt. Eine SWF-Datei erteilt SWF-Dateien von anderen Domänen die Skriptfreigabe durch Aufrufen von Security.allowDomain(). Dies wird als Cross-Domain-Scripting bezeichnet. Durch Aufrufen von Security.allowDomain("siteA.com") erteilt siteB.swf der Datei siteA.swf die Berechtigung zur Skripterstellung.

In domänenübergreifenden Situationen ist es wichtig, die betreffenden beiden Seiten klar zu trennen. In der vorliegenden Erläuterung soll die Seite, die das Cross-Scripting durchführt, als accessing party (normalerweise die zugreifende SWF), und die andere Seite als die Seite, auf die zugegriffen wird (normalerweise die SWF, auf die zugegriffen wird) bezeichnet werden. Wenn siteA.swf die Skripterstellung von siteB.swf durchführt, handelt es sich bei siteA.swf um die zugreifende Seite und bei siteB.swf um die Seite, auf die zugegriffen wird.

Mit allowDomain() hergestellte domänenübergreifende Berechtigungen sind asymmetrisch. Im vorherigen Beispiel kann siteA.swf die Skripterstellung von siteB.swf durchführen, siteB.swf jedoch keine Skripterstellung von siteA.swf, da siteA.swf nicht allowDomain() aufgerufen hat, um SWF-Dateien auf siteB.com die Berechtigung zur Skripterstellung zu erteilen. Sie können jedoch symmetrische Berechtigungen einrichten, indem Sie allowDomain() aus beiden SWF-Dateien aufrufen.

Flash Player schützt SWF-Dateien nicht nur vor Cross-Domain-Scripting durch andere SWF-Dateien, sondern auch vor Cross-Domain-Scripting durch HTML-Dateien. Die HTML-für-SWF-Skripterstellung kann mit älteren Flash-Browserfunktionen wie SetVariable oder durch Aufrufe über ExternalInterface.addCallback() durchgeführt werden. Bei domänenübergreifender HTML-für-SWF-Skripterstellung muss die SWF-Datei, auf die zugegriffen wird, allowDomain() genauso aufrufen, als ob es sich bei der zugreifenden Seite um eine SWF-Datei handelt, andernfalls schlägt der Vorgang fehl.

Die Angabe einer IP-Adresse als Argument für allowDomain() gestattet keinen Zugriff durch alle zugreifenden Seiten, die von der angegebenen IP-Adresse stammen. Stattdessen erhält hierdurch nur eine Seite Zugriff, die in der URL die angegebene IP-Adresse und nicht den Domänennamen enthält, der dieser IP-Adresse zugeordnet ist.

Versionsspezifische Unterschiede

Die domänenübergreifenden Sicherheitsregeln von Flash Player wurden von Version zu Version weiterentwickelt. Die Unterschiede sind in der folgenden Tabelle zusammengefasst.

Die Versionen, die das Verhalten von Flash Player steuern, sind SWF-Versionen (Veröffentlichungsversionen einer SWF), nicht die Version von Flash Player selbst. Beispiel: Wenn Flash Player 8 eine SWF wiedergibt, die für Version 7 veröffentlicht wurde, wendet Flash Player das Verhalten von Version 7 an. Hierdurch wird sichergestellt, dass Upgrades des Players keinen Einfluss auf das Verhalten von Security.allowDomain() in bereitgestellten SWFs haben.

Die Spalte "Version" in der vorherigen Tabelle gibt jeweils die neueste SWF-Version an, die an einem Cross-Scripting-Vorgang beteiligt ist. Flash Player legt das Verhalten entweder nach der Version der zugreifenden SWF-Datei oder der Version der SWF-Datei fest, auf die zugegriffen wird, je nachdem, welche der beiden Versionen neuer ist.

Die folgenden Absätze enthalten weitere Informationen zu den Sicherheitsänderungen in Flash Player mit Bezug auf Security.allowDomain().

Version 5. Beim Cross-Domain-Scripting liegen keine Beschränkungen vor.

Version 6. Einführung der Cross-Domain-Scripting-Sicherheit. Standardmäßig verbietet Flash Player das Cross-Domain-Scripting. Mit Security.allowDomain() kann es jedoch zugelassen werden. Um festzustellen, ob sich zwei Dateien in derselben Domäne befinden, verwendet Flash Player die Superdomäne der jeweiligen Datei. Diese entspricht exakt dem Hostnamen aus der URL der Datei, minus dem ersten Segment, bis zu einem Minimum von zwei Segmenten. Beispiel: Die Superdomäne www.mysite.com lautet einfach mysite.com. In diesem Fall könnten SWFs sowohl von www.mysite.com als auch von store.mysite.com Skripts für einander erstellen, ohne Security.allowDomain() aufzurufen.

Version 7. Superdomänen-Übereinstimmung wird durch exakte Domänenübereinstimmung ersetzt. Zwei Dateien haben aufeinander nur dann Skriptzugriff, wenn die Hostnamen in ihren URLs identisch sind. Andernfalls ist ein Aufruf von Security.allowDomain() erforderlich. In der Standardeinstellung haben Dateien, die aus Nicht-HTTPS-URLs geladen werden, keinen Skriptzugriff mehr auf Dateien, die aus HTTPS-URLs geladen werden, auch wenn diese Dateien aus exakt derselben Domäne geladen werden. Diese Einschränkung trägt zum Schutz von HTTPS-Dateien bei, da eine Nicht-HTTPS-Datei beim Herunterladen modifiziert werden kann. Eine absichtlich modifizierte Nicht-HTTPS-Datei kann eine HTTPS-Datei beschädigen, die ansonsten gegen Aktionen dieser Art geschützt wäre. Mit Security.allowInsecureDomain() können HTTPS-SWF-Dateien, auf die zugegriffen wird, diese Einschränkung bei Bedarf aufheben. Von der Verwendung von Security.allowInsecureDomain() wird jedoch abgeraten.

Version 8. Änderungen in zwei wichtigen Bereichen:

• Durch Aufrufen von Security.allowDomain() sind Cross-Scripting-Vorgänge nun nur noch dann möglich, wenn die SWF-Datei, auf die zugegriffen wird, die Datei ist, die Security.allowDomain() aufgerufen hat. Mit anderen Worten: Eine SWF-Datei, die Security.allowDomain() aufruft, gibt nun nur den Zugriff auf sich selbst frei. In früheren Versionen ermöglichte der Aufruf von Security.allowDomain() Cross-Scripting-Vorgänge, bei denen die SWF-Datei, auf die zugegriffen wurde, jede SWF-Datei in der Domäne der SWF-Datei sein konnte, die Security.allowDomain() aufgerufen hat. Durch den Aufruf von Security.allowDomain() wurde bisher die gesamte Domäne der aufrufenden SWF-Datei freigegeben.
• Für Security.allowDomain("*") und Security.allowInsecureDomain("*") werden nun Werte mit Platzhalterzeichen unterstützt. Der Platzhalter (*) ermöglicht Cross-Scripting-Vorgänge, bei denen die zugreifende Datei jede beliebige Datei aus einer beliebigen Quelle sein kann. Der Platzhalter ist gewissermaßen eine globale Berechtigung. Berechtigungen durch Platzhalter sind zum Aktivieren bestimmter Vorgänge unter den Sicherheitsregeln für lokale Dateien erforderlich. Insbesondere bei einer lokalen SWF-Datei mit Berechtigung für den Netzwerkzugriff zum Erstellen von Skripts für eine SWF-Datei im Internet muss die Internet-SWF-Datei, auf die zugegriffen wird, die Methode Security.allowDomain("*") aufrufen, um der Tatsache Rechnung zu tragen, dass der Ursprung einer lokalen SWF-Datei unbekannt ist. (Wenn die Internet-SWF-Datei von einer HTTPS-URL geladen wird, muss die Internet-SWF-Datei stattdessen die Methode Security.allowInsecureDomain("*") aufrufen.)

Von Zeit zu Zeit stellt sich Ihnen folgende Situation: Sie laden eine untergeordnete SWF-Datei aus einer anderen Domäne und möchten dieser das Scripting für die übergeordnete SWF-Datei ermöglichen, Ihnen ist jedoch die endgültige Domäne der untergeordneten SWF-Datei nicht bekannt. Dies ist beispielsweise der Fall, wenn Sie Weiterleitungen mit Lastausgleich oder Server von Dritten verwenden.

Sie können dann die url-Eigenschaft des URLRequest-Objekts verwenden, das für Loader.load() übergeben wird. Wenn Sie beispielsweise eine untergeordnete SWF-Datei in einer übergeordneten SWF-Datei laden, können Sie auf die contentLoaderInfo-Eigenschaft des Loader-Objekts für die übergeordnete SWF-Datei zugreifen:

Security.allowDomain(loader.contentLoaderInfo.url)

Warten Sie, bis der Ladevorgang der untergeordneten SWF-Datei gestartet wird, um den korrekten Wert der url-Eigenschaft abrufen zu können. Über das progress-Ereignis können Sie feststellen, wann der Ladevorgang der untergeordneten SWF-Datei gestartet wurde.

Es kann auch die entgegengesetzte Situation auftreten: Angenommen, Sie haben eine untergeordnete SWF-Datei erstellt, die das Scripting durch die übergeordnete SWF-Datei ermöglichen soll, der jedoch die Domäne der übergeordneten SWF-Datei nicht bekannt ist. In diesem Fall können Sie auf die loaderInfo-Eigenschaft des Anzeigeobjekts zugreifen, bei dem es sich um das Stammobjekt der SWF-Datei handelt. Rufen Sie Security.allowDomain( this.root.loaderInfo.loaderURL) in der untergeordneten SWF-Datei auf. Sie müssen nicht warten, bis die übergeordnete SWF-Datei geladen wurde, da der Ladevorgang der übergeordneten Datei bereits abgeschlossen ist, wenn der Ladevorgang für die untergeordnete SWF-Datei erfolgt.

Wenn Sie eine Datei für Flash Player 8 oder eine spätere Version veröffentlichen, können Sie in diesen Fällen auch Security.allowDomain("*") aufrufen. Dies ist jedoch mitunter gefährlich, da hierdurch die aufrufende SWF-Datei für den Zugriff durch jede andere SWF-Datei der Domäne geöffnet wird. In der Regel ist es sicherer, die Eigenschaft _url zu verwenden.

Weitere Informationen finden Sie in den folgenden Abschnitten:

• Das Kapitel Sicherheit im Handbuch Programmieren mit ActionScript 3.0 und die neusten Kommentare zu den LiveDocs.
• Das Flash Player 9-Whitepaper zum Thema Sicherheit

Parameter

Siehe auch

Hiermit können SWF- und HTML-Dateien in den angegebenen Domänen auf Objekte und Variablen in der aufrufenden SWF-Datei zugreifen, die über das HTTPS-Protokoll gehostet wird. Von der Verwendung dieser Methode wird abgeraten, siehe auch "Sicherheitserwägungen" weiter unten.

Diese Methode funktioniert genauso wie Security.allowDomain(), erlaubt jedoch zusätzlich Operationen, bei denen die zugreifende Seite mit einem Nicht-HTTPS-Protokoll und die Seite, auf die zugegriffen wird, mit HTTPS geladen werden. In Flash Player ab Version 7 erhalten Nicht-HTTPS-Dateien keinen Skriptzugriff auf HTTPS-Dateien. Die Methode allowInsecureDomain() hebt diese Einschränkung auf, wenn sie von der HTTPS-SWF verwendet wird, auf die zugegriffen wird.

Verwenden Sie allowInsecureDomain() nur, um den Skriptzugriff durch Nicht-HTTPS-Dateien auf HTTPS-Dateien zu ermöglichen. Verwenden Sie diese Methode zum Ermöglichen der Skripterstellung, wenn die zugreifende Nicht-HTTPS-Datei und die HTTPS-Datei, auf die zugegriffen wird, von derselben Domäne aus bereitgestellt werden, beispielsweise, wenn eine SWF-Datei auf http://mysite.com Skripts für https://mysite.com erstellen soll. Verwenden Sie die Methode nicht, um eine Skripterstellung zwischen Nicht-HTTPS-Dateien, zwischen HTTPS-Dateien oder seitens HTTPS-Dateien bei Nicht-HTTPS-Dateien zu ermöglichen. Für diese Fälle sollten Sie die Methode allowDomain() verwenden.

Sicherheitserwägungen: Flash Player stellt allowInsecureDomain() bereit, um maximale Flexibilität zu bieten. Es wird jedoch davon abgeraten, diese Methode aufzurufen. Beim Bereitstellen einer Datei über HTTPS sind einige Schutzvorkehrungen für Sie und die Benutzer aktiv. Durch Aufrufen von allowInsecureDomain wird eine dieser Schutzvorkehrungen geschwächt. Das folgende Szenario verdeutlicht, wie allowInsecureDomain() bei unsachgemäßer Anwendung die Sicherheit gefährden kann.

Beachten Sie, dass das folgende Beispiel nur ein mögliches Szenario darstellt. Es soll lediglich die Problematik von allowInsecureDomain() anhand eines realistischen Beispiels für Cross-Scripting verdeutlichen. Es deckt jedoch nicht alle Probleme bezüglich der Sicherheitsarchitektur ab und sollte nur als Hintergrundinformation betrachtet werden. Im Flash Player Developer Center stehen umfangreiche Informationen zum Thema Flash Player und Sicherheit zur Verfügung. Weitere Informationen finden Sie unter http://www.adobe.com/devnet/security/.

Angenommen, Sie möchten eine E-Commerce-Site erstellen, die aus zwei Komponenten besteht: einem Katalog, der nicht sicher zu sein braucht, da er nur öffentliche Informationen enthält, und einer Einkaufswagen-/Bezahlkomponente, die sicher sein muss, um finanzspezifische und persönliche Daten der Benutzer zu schützen. Der Katalog soll von http://mysite.com/catalog.swf aus bereitgestellt werden, der Einkaufswagen von https://mysite.com/cart.swf. Eine Anforderung an die Site besteht darin, dass kein Dritter die Kreditkartennummern Ihrer Benutzer ausspionieren kann, indem er eine Schwachstelle in der Sicherheitsarchitektur nutzt.

Stellen Sie sich vor, dass sich ein Angreifer zwischen Ihren Server und Ihre Benutzer platziert, um zu versuchen, die Kreditkartennummern abzufangen, die die Benutzer in der Einkaufswagen-Anwendung eingeben. Ein solcher Angreifer kann beispielsweise ein skrupelloser Internet-Dienstanbieter (ISP) sein, der von einem Ihrer Benutzer verwendet wird, oder ein böswilliger Administrator am Arbeitsplatz des Benutzers – im Grunde jeder, der die Fähigkeit besitzt, Netzwerkpakete einzusehen oder zu ändern, die über das öffentliche Internet zwischen Ihren Benutzern und Ihren Servern übertragen werden. Diese Situation ist nicht ungewöhnlich.

Wenn cart.swf die Kreditkartendaten mittels HTTPS an Ihre Server überträgt, kann der Angreifer diese Informationen nicht direkt aus den Netzwerkpaketen stehlen, da es sich um eine verschlüsselte Übertragung handelt. Er kann jedoch eine andere Technik anwenden: den Inhalt einer Ihrer SWF-Dateien ändern, während diese dem Benutzer bereitgestellt wird, d. h. die SWF-Datei durch eine andere Version ersetzen, die die Benutzerdaten an einen anderen vom Angreifer betriebenen Server überträgt.

Das HTTPS-Protokoll verhindert u. a., dass eine solche Modifikation durchgeführt wird, da HTTPS-Übertragungen nicht nur verschlüsselt, sondern auch manipulationssicher sind. Wenn ein Angreifer ein Paket ändert, erkennt die empfangende Seite diese Änderung und verwirft das Paket. In diesem Fall kann der Angreifer also die Datei cart.swf nicht ändern, da die Übertragung über HTTPS erfolgt.

Doch nun möchten Sie, dass in der über HTTP bereitgestellten Datei catalog.swf Artikel mittels Schaltflächen dem Einkaufswagen in cart.swf hinzugefügt werden können, der seinerseits über HTTPS bereitgestellt wird. Dazu ruft cart.swf die Methode allowInsecureDomain() auf, über die der Katalog (catalog.swf) ein Skript für cart.swf erstellen kann. Diese Aktion hat eine nicht beabsichtigte Folge: Der Angreifer kann nun bereits Änderungen an der Datei catalog.swf vornehmen, während der Benutzer sie herunterlädt, da sie mittels HTTP übertragen wird und somit nicht manipulationssicher ist. Die geänderte catalog.swf des Angreifers kann nun ein Skript für cart.swf erstellen, da cart.swf einen Aufruf der Methode allowInsecureDomain() enthält. Die geänderte Datei catalog.swf kann mithilfe von ActionScript auf die Variablen in cart.swf zugreifen und somit die Kreditkartendaten und andere vertrauliche Informationen des Benutzers lesen. Die geänderte catalog.swf kann diese Daten dann an den Server des Angreifers senden.

Ein solcher Missbrauch ist natürlich nicht erwünscht, Sie möchten dennoch, dass Cross-Scripting zwischen den beiden SWF-Dateien Ihrer Site möglich ist. Im Folgenden sind zwei Möglichkeiten aufgeführt, wie Sie diese hypothetische E-Commerce-Site so umbauen können, dass allowInsecureDomain() verhindert wird:

• Bereitstellen aller SWF-Dateien der Anwendung über HTTPS: Dies ist die bei weitem einfachste und zuverlässigste Lösung. Im genannten Beispiel würden Sie sowohl catalog.swf als auch cart.swf über HTTPS übertragen. Eventuell bemerken Sie ein etwas höheres Datenverkehrsaufkommen und eine etwas stärkere CPU-Auslastung des Servers, wenn Sie eine Datei wie catalog.swf von HTTP auf HTTPS umstellen, und für Ihre Benutzer kommt es eventuell zu etwas längeren Anwendungsladezeiten. Um die Auswirkung dieser Umstellung zu testen, sollten Sie mit reellen Servern experimentieren. Normalerweise liegt die Datenverkehrserhöhung in einem Bereich von 10 bis 20 Prozent. Manchmal ist auch gar keine Erhöhung feststellbar. In der Regel können Sie die Ergebnisse mithilfe von HTTPS-Beschleunigungshardware oder -software weiter optimieren. Ein entscheidender Vorteil der Bereitstellung aller kooperierenden SWF-Dateien über HTTPS besteht darin, dass Sie eine HTTPS-URL als Haupt-URL im Browser des Benutzers verwenden können, ohne dass der Browser Warnmeldungen bezüglich gemischtem Inhalt ausgibt. Darüber hinaus wird dem Benutzer das Schlosssymbol des Browsers als ihm bekanntes und vertrauenswürdiges Zeichen für Sicherheit angezeigt.
• Verwenden des HTTPS-auf-HTTP-Skriptzugriffs anstelle des HTTP-auf-HTTPS-Skriptzugriffs: Im genannten Beispiel könnten Sie den Inhalt des Einkaufswagens eines Benutzers in catalog.swf speichern, während cart.swf nur für das Bezahlen zuständig ist. Beim Auschecken kann die Datei cart.swf den Inhalt des Einkaufwagens aus ActionScript-Variablen der Datei catalog.swf abrufen. Die Beschränkung auf HTTP-zu-HTTPS-Skripts ist asymmetrisch. Obwohl eine über HTTP-übermittelte catalog.swf-Datei nicht sicher für Skript-Operationen in einer über HTTPS übermittelten cart.swf-Datei freigegeben werden kann, kann die HTTPS-cart.swf-Datei Änderungen in der HTTP-catalog.swf-Datei vornehmen. Dieser Ansatz ist feiner als der reine HTTPS-Ansatz. Achten Sie jedoch darauf, nicht allen per HTTP übermittelten SWF-Dateien zu vertrauen, da diese manipuliert werden können. Wenn beispielsweise cart.swf die ActionScript-Variable abruft, die den Inhalt des Einkaufswagens beschreibt, kann der ActionScript-Code in cart.swf nicht darauf vertrauen, dass der Wert dieser Variable im erwarteten Format vorliegt. Sie müssen deshalb darauf achten, dass der Inhalt des Einkaufswagens keine ungültigen Daten enthält, die cart.swf zu einer unerwünschten Aktion veranlassen könnte. Sie müssen auch das Risiko einkalkulieren, dass ein Angreifer durch Ändern von catalog.swf zwar gültige, aber inkorrekte Daten an cart.swf übermitteln könnte. So könnte er z. B. Artikel in den Einkaufswagen des Benutzers schmuggeln. Beim üblichen Bezahlvorgang wird das Risiko dadurch ein wenig abgemildert, dass der Inhalt des Einkaufswagens und der Gesamtbetrag erneut zur abschließenden Bestätigung durch den Benutzer angezeigt wird, doch grundsätzlich bleibt das Risiko bestehen.

Die gängigen Webbrowser unterscheiden bereits seit Jahren zwischen HTTPS- und Nicht-HTTPS-Dateien. Das erläuterte Szenario verdeutlicht, weshalb diese Unterscheidung so wichtig ist. Flash Player bietet die Möglichkeit, diese Sicherheitsvorkehrung zu umgehen, wenn dies absolut erforderlich ist. Zuvor sollten Sie sich jedoch die möglichen Folgen sehr genau bewusst machen.

Weitere Informationen finden Sie in den folgenden Abschnitten:

• Das Kapitel Sicherheit im Handbuch Programmieren mit ActionScript 3.0 und die neusten Kommentare zu den LiveDocs.
• Das Flash Player 9-Whitepaper zum Thema Sicherheit

Parameter

Siehe auch

Lädt eine domänenübergreifende Richtlinie von einem Speicherort, der durch den url-Parameter angegeben wird. In Flash Player wird mithilfe von Richtliniendateien festgelegt, ob über Flash-Movieclips Daten von Servern geladen werden können, bei denen es sich nicht um ihren eigenen Server handelt.

In der Standardeinstellung wird in Flash Player nur an einem Speicherort nach Richtliniendateien gesucht: /crossdomain.xml auf dem Server, auf dem die Anforderung zum Laden von Daten erfolgt ist.

Mithilfe von Security.loadPolicyFile() kann Flash Player Richtliniendateien von beliebigen Orten laden, wie im folgenden Beispiel veranschaulicht wird:

  Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");
  

Damit ruft Flash Player eine Richtliniendatei von der angegebenen URL ab. Alle an diesem Speicherort von der Richtliniendatei zugelassenen Berechtigungen gelten auch für alle Inhalte auf der gleichen oder einer niedrigeren Stufe in der virtuellen Verzeichnishierarchie des Servers. Beispielsweise wird bei den folgenden zusätzlichen Codezeilen keine Ausnahme ausgelöst:

 import flash.net.*;
  var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
  var loader:URLLoader = new URLLoader();
  loader.load(request);
  
  var loader2:URLLoader = new URLLoader();
  var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
  loader2.load(request2);
  

Beim folgenden Code wird jedoch eine Sicherheitsausnahme ausgelöst:

 import flash.net.*;
  var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
  var loader3:URLLoader = new URLLoader();
  loader3.load(request3);
  

Mit loadPolicyFile() können Sie beliebig viele Richtliniendateien laden. Beim Prüfen einer Anforderung, für die eine Richtliniendatei erforderlich ist, wartet Flash Player immer, bis der Download der Richtliniendatei abgeschlossen ist, bevor eine Anforderung zurückgewiesen wird. Wenn keine Richtliniendatei die Anforderung mit loadPolicyFile() autorisiert, konsultiert Flash Player in letzter Instanz den ursprünglichen Standardspeicherort /crossdomain.xml.

Durch Verwendung des xmlsocket-Protokolls zusammen mit einer spezifischen Portnummer können Sie Richtliniendateien direkt von einem XMLSocket-Server abrufen, wie im folgenden Beispiel veranschaulicht:

  Security.loadPolicyFile("xmlsocket://foo.com:414");
  

Damit versucht Flash Player, eine Richtliniendatei von dem angegebenen Host und Port abzurufen. Hierbei kann ein beliebiger Port verwendet werden, nicht nur Port 1024 und höher. Wurde eine Verbindung mit dem angegebenen Port hergestellt, sendet Flash Player <policy-file-request />, beendet mit einem null-Byte. Es ist möglich, einen XMLSocket-Server so zu konfigurieren, dass Richtliniendateien und herkömmliche XMLSocket-Verbindungen über den gleichen Port bereitgestellt werden. In diesem Fall muss der Server auf <policy-file-request /> warten, bevor er eine Richtliniendatei sendet. Ein Server kann auch zum Bereitstellen von Richtliniendateien über einen anderen Port als die Standardverbindungen konfiguriert werden. In diesem Fall kann eine Richtliniendatei gesendet werden, sobald die Verbindung über den dedizierten Richtliniendatei-Port hergestellt ist. Der Server muss zum Beenden einer Richtliniendatei ein Null-Byte senden und kann die Verbindung anschließend schließen. Tut er dies nicht, schließt Flash Player die Verbindung nach Erhalt des beendenden null-Bytes.

Eine Richtliniendatei, die von einem XMLSocket-Server bereitgestellt wird, verfügt über dieselbe Syntax wie alle anderen Richtliniendateien. Es müssen allerdings auch die Ports angegeben werden, auf die Zugriff gewährt wird. Wenn eine Richtliniendatei von einem Port unter 1024 stammt, kann sie Zugriff auf beliebige Ports gewähren. Stammt sie dagegen von Port 1024 oder höher, kann sie nur Zugriff auf andere Ports mit der Nummer 1024 oder höher gewähren. Die zulässigen Ports werden im Attribut "to-ports" im Tag <allow-access-from> angegeben. Einzelne Portnummern, Portbereiche und Platzhalterzeichen sind zulässig. Im folgenden Beispiel ist eine XMLSocket-Richtliniendatei dargestellt:

  <cross-domain-policy>
    <allow-access-from domain="*" to-ports="507" />
    <allow-access-from domain="*.foo.com" to-ports="507,516" />
    <allow-access-from domain="*.bar.com" to-ports="516-523" />
    <allow-access-from domain="www.foo.com" to-ports="507,516-523" />
    <allow-access-from domain="www.bar.com" to-ports="*" />
  </cross-domain-policy>
  

Eine vom alten Standardspeicherort, /crossdomain.xml auf einem HTTP-Server auf Port 80, abgerufene Richtliniendatei autorisiert implizit den Zugriff auf alle Ports ab 1024. Es ist nicht möglich, eine Richtliniendatei abzurufen, um XMLSocket-Operationen von einem anderen Speicherort auf einem HTTP-Server zu autorisieren. Benutzerdefinierte Speicherorte für XMLSocket-Richtliniendateien müssen sich immer auf einem XMLSocket-Server befinden.

Die Fähigkeit, eine Verbindung zu Ports unter 1024 herzustellen, kann durch eine mithilfe von loadPolicyFile() geladene Richtliniendatei gewährt werden.

Sie können eine SWF-Datei daran hindern, diese Methode aufzurufen, indem Sie in der HTML-Seite, die den SWF-Inhalt enthält, den Parameter allowNetworking der Tags object und embed festlegen.

Weitere Informationen finden Sie in den folgenden Abschnitten:

• Das Kapitel Sicherheit im Handbuch Programmieren mit ActionScript 3.0 und die neusten Kommentare zu den LiveDocs.
• Das Flash Player 9-Whitepaper zum Thema Sicherheit

Parameter

Siehe auch

Zeigt das Bedienfeld für die Sicherheitseinstellungen in Flash Player an.

Parameter

Siehe auch

Die SWF-Datei ist eine lokale Datei, die für den Benutzer über den Einstellungsmanager oder eine FlashPlayerTrust-Konfigurationsdatei als vertrauenswürdig gekennzeichnet wurde. Die SWF-Datei kann lokale Datenquellen lesen und eine Verbindung mit dem Internet herstellen.

Siehe auch

Die SWF-Datei ist eine lokale Datei, die für den Benutzer nicht vertrauenswürdig ist und nicht für die Verwendung im Netzwerk veröffentlicht wurde. Die SWF-Datei kann lokale Datenquellen lesen, jedoch keine Verbindung mit dem Internet herstellen.

Siehe auch

Die SWF-Datei ist eine lokale Datei, die für den Benutzer nicht vertrauenswürdig ist und für die Verwendung im Netzwerk veröffentlicht wurde. Die SWF-Datei kann eine Verbindung mit dem Internet herstellen, jedoch keine lokalen Datenquellen lesen.

Siehe auch

Die SWF-Datei stammt von einer Internet-URL und kann entsprechend den domänenbasierten Sandbox-Regeln verwendet werden.

Siehe auch