Mit Hilfe von ActionScript können Dateien von externen Quellen geladen werden, dies können Grafik-, Text-, XML- oder auch andere Flashdateien sein.
Damit dies aber einwandfrei funktioniert muss man das Sicherheitsmodell von Adobe Flash verstehen.
Inhalt
Zuerst einmal ein paar Hintergrund Informationen warum es wichtig ist sich mit dem Sicherheitsmodell zu beschäftigen.
Nehmen wir mal an, ein böser Cracker (nicht zu verwechseln mit Hacker) schreibt ein Flashspiel, aber mit einer bösen Absicht.
Sobald der User die Flashdatei im Browser lädt, sucht diese lokal nach einer Datei und schick Sie an einem Server, diese Datei kann z.B: eine Passwortdatei sein oder aber irgendwelche Logfiles.
Kommen wir zum nächsten Beispiel, der böser Cracker soll für eine Firma ein Flashprogramm schreiben damit die Abrechnung erleichtert wird, hier werden Kundendaten und andere Daten eingepflegt.
Die Flashdatei befindet sich auf den PC des Users und diese wurde so modifiziert das Sie täglich diese Kundendaten an einen Server im Internet schickt.
Ohne ein Sicherheitsmodell wäre die Benutzung von Adobe Flash also mehr als Gefährlich, jedoch blockt das Standart Sicherheitsmodell genauso dies.
Flash Dateien von einer Webseiten dürfen also nicht auf Dateien von PC zugreifen, genauso wenig darf eine Flashdatei auf den PC auf Daten im Internet zugreifen.
Man unterscheidet hier das Sicherheitmodell einer so genannte Sandbox die ohne zusätzliche Einstellungen die Beispiele von oben blocken würde.
Das andere sind Sicherheits Richtlinien wenn eine Flashdatei im Internet auf eine andere Flashdatei im Internet zugreifen oder diese steuern will.
Es gibt verschiedene Sandbox, welche genau festlegen wie die Kommunikation zwischen einer SWF-Datei und dem lokalen Dateisystem, dem Netzwerk oder gleichzeitig mit dem lokalen Dateisystem und dem Netzwerk erfolgt.
Grundlegend sind hier nachfolgende Sandboxen wichtig, jeder Flashentwickler sollte diese Sandboxen kennen um Probleme mit Sicherheitsrichtlinien zu vermeiden.
| Sandbox | Beschreibung | ||
|---|---|---|---|
| Local-with-file-system | (Standartwert für Adobe Flash 8) Lesender Zugriff auf das lokale Dateisystemen oder UNC-Netzwerkpfaden z.B: über XML.load(). Jedoch ist keine Kommunikation mit dem Netzwerk oder Internet möglich, damit die Daten nicht unbefugt weiter gegen werden können. |
||
| Local-with-networking | Kein Zugriff auf lokale Dateisystem, jedoch vollständiger Netzwerkzugriff soweit die Rechte dies erlauben. Es können also Daten zum Netzwerk oder Internet gesendet werden und empfangen werden. |
||
| Local-trusted | Diese Sandbox erlaubt den vollständigen Zugriff auf das Netzwerk, das Internet und das lokale Dateisystem. | ||
In welcher Sandbox eine Flashdatei gestartet wird kann teilweise beim abspeichern der Flashdatei festgelegt werden (Flash Editor 8 und höher).
Der Modus Local-trusted kann jedoch nicht vom Flash Author beeinflusst werden, hier muss der User eine extra Konfigurationsdatei festlegen und auch die genannte Flashdatei explizit dafür freischalten.
Festlegen der lokalen Sandbox in Adobe Flash
Die lokale Sandbox kann recht einfach in Flasheditor festgelegt werden, unter Veröffentlichen: Einstellungen erscheint nachfolgendes Fenster wo man zwischen Nur auf lokale Dateien zugreifen oder Nur auf Netzwerk zugreifen wählen kann.
Die crossdomain.xml wird immer dann benötigt, wenn eine SWF Datei im Internet versucht Daten (SWF, Grafik, XML, Text) von einer anderen Domain zu laden.
Es muss in dieser Datei festgelegt werden, welche Domains Zugriff auf spezielle Daten haben dürfen.
Mal angenommen eine Kreativagentur hat eine SWF Datei welche ein Video abspielen soll, da die Kreativagentur aber keinen großen Webserver hat, mieten Sie eine welcher aber unter einer komplett anderen Domain zu erreichen ist.
Damit die SWF Datei nun das Video laden kann, muss auf den Webserver wo dieses Video liegt eine entsprechende crossdomain.xml hinterlegt sein die den Zugriff von Flash erlaubt.
Diese Datei liegt also immer dort, wovon die SWF die Daten laden muss.
Meist wird die Datei direkt unter der Hauptdomain anlegt z.B: http://area-network.de/crossdomain.xml .
Beispiel einer Crossdomain.xml
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="www.example.com" />
<allow-access-from domain="*.area-network.de" />
<allow-access-from domain="105.216.0.40" />
<allow-access-from domain="www.adobe.com" secure="false"/>
</cross-domain-policy>
Der Aufbau der crossdomain.xml ist immer der selbe, durch allow-access-from wird der erlaubte Zugriff gesteuert.
Sollte diese Datei also auf einen Webserver verwendet werden, so dürften SWF Dateien die auf http://www.example.com, http://*.area-network.de oder aber auf http://105.216.0.40 liegen auf die Daten von diesem Webserver zugreifen.
Falls eine IP-Addresse verwendet wird, kann nur eine SWF Datei von der IP Addresse auf die Daten zugreifen, Flash führt keine Namesauflösung durch !
Standartmässig wird das Attribut secure="true" gesetzt, es ist also nicht nötig dies im normal Fall hinzu zufügen.
Falls dieses Attribute auf secure="false" gesetzt wird, wie in dem Beispiel bei www.adobe.com, so darf die Flashdatei die auf einem https Server liegt die Daten von einem http Server abrufen.
Jedoch wenn dieses Attribut nicht gesetzt ist, darf eine Flashdatei die auf https liegt (https://www.adobe.com) nicht auf die Daten von einem http Server zugreifen (http://flash.area-network.de).
Auch ist es ein Unterschied ob die Flashdatei mit http://www.example.com aufgerufen wird oder aber mit http://example.com.
Da die crossdomain.xml leider nicht viele Einstellungen zulässt wurde mit dem Flash Player Version 7.0.19.0 loadPolicyFile() eingefügt.
Alle Flash Player Version darunter suchen nur nach einer crossdomain.xml, des weiteren war kein Zugriff auf den Port 1024 und höher möglich, was bei einigen XML Server zu Problemen führte.
Mit loadPolicyFile() kann festgelegt werden wo Adobe Flash die Richtliniendatei lädt, dem entsprechenden setzen sich dann auch die Rechte zusammen.
Es ist auch möglich mehrere Regeln zu verwenden, so kann man nur spezielle Ordner bzw. Unterordner freigeben.
Grundsätzlich hat loadPolicyFile Vorrang gegenüber crossdomain.xml.
Es werden zuerst alle loadPolicyFile Regeln durchgesehen, falls keine zutrifft wird die crossdomain.xml geprüft.
Beispiel
System.security.loadPolicyFile("http://flash.area-network.de/sub/dir/policyfile.xml");
| URL | Zugriff | ||
|---|---|---|---|
| http://flash.area-network.de/sub/dir/data.xml | ERLAUBT | ||
| http://flash.area-network.de/sub/dir/subdir/data.xml | ERLAUBT | ||
| http://flash.area-network.de/dir/data.xml | NICHT ERLAUBT | ||
Das obere Beispiel erlaubt also keinen Zugriff auf http://flash.area-network.de/dir/data.xml, da hier kein PolicyFile vorhanden ist.
Sollte man hier Daten benötigen, so müsste eine weitere LoadPolicy verwendet werden oder die vorhandene wird einfach verschoben.
Aufbau einer LoadPolicy
<cross-domain-policy>
<allow-access-from domain="*" to-ports="507" />
<allow-access-from domain="*.area-network.de" to-ports="507,516" />
<allow-access-from domain="*.example.com" to-ports="516-523" />
<allow-access-from domain="flash.area-network.de" to-ports="507,516-523" />
<allow-access-from domain="www.example.com" to-ports="*" />
</cross-domain-policy>
| Domain | Port | Zugriff | |
|---|---|---|---|
| flash.area-network.de | 507 | ERLAUBT | |
| google.de | 507 | ERLAUBT | |
| google.de | 690 | NICHT ERLAUBT | |
| test.area-network.de | 507 und 516 | ERLAUBT | |
| test.area-network.de | 511 | NICHT ERLAUBT | |
| flash.area-network.de | 507 und 516 bis 523 | ERLAUBT | |
| www.example.com | allen | ERLAUBT | |
Wie man hier sieht kann man den Zugriff sehr leicht einschränken, vor allem die Freigabe einzelner Ports ist wichtig hier kann z.B: der Zugriff auf den XML Server beschränkt werden anstatt Systemweit auf alle Dienste und Ports.
Es ist auch möglich das Policy File über einen XML Server abzurufen z.B. mit xmlsocket://example.com:414. Dieser Befehl würde versuchen von example.com von Port 414 das Policy File zu erhalten.
Wenn sich 2 Flashdateien auf der selben Domain befinden, so kann die einen Flashdatei von der anderen Flashdatei alle Variablen, Objekte, Eigenschaften, Methoden auslesen und ändern.
Dieses Verhalten wird Cross-Scripting genannt, da die eine Flashdatei die andere Flashdatei steuern kann, als wäre es 1 Flashdatei.
Liegen die Flashdateien jedoch auf verschiedenen Domain so wird Cross-Scripting vom Flashplayer blockiert.
Es gibt jedoch Situation wo man genau dies benötigt und genau hierfür wird allowDomain benötigt.
Hiermit kann festlegen welche Domain die Flashdatei steuern darf welche allowDomain enthält.
Grundsätzlicher Ablaufe von Cross-Scripting
Im ersten Schritt wird die Flashdatei MovieB.swf von der Flashdatei MovieA.swf geladen (1). Hier die crossdomain.xml nicht vergessen, da etwas von einer anderen Domain geladen wird.
Während dem Ladevorgang (2) prüft MovieB.swf ob ein allowDomain Eintrag vorhanden ist, wenn dieser vorhanden ist ob die Domain von MovieA.swf darin vorkommt.
Nach einer erfolgreichen Prüfung kann/darf MovieA.swf die Variable (3) GameScore von der Flashdatei MovieB.swf ändern.
Des weiteren kann MovieA.swf auch die Funktion von MovieB.swf um sich die GameScore anzeigen zu lassen.
Beispiele
Der Befehl allowDomain kann mehrmals aufgerufen werden um mehrer Domains den Zugriff bzw. die Steuerung auf eine Flashdatei zu ermöglichen.
Für Localconnection gibt es auch die Möglichkeit mit allowDomain Localconnections zwischen verschiedenen Domains herzustellen.
System.security.allowDomain("area-network.de");
System.security.allowDomain("example.com");
System.security.allowDomain("example.org");
System.security.allowDomain("area-network.de");
Versions Einschränkungen
Es gibt je nach Flashplayer Version mehr oder weniger Optionen die allowDomain unterstütz.
Anbei eine kurze Zusammenfassung welche diese im Detail sind, da allowDomain erst ab FlashPlayer 6 unterstützt wird tauchen hier die FlashPlayer 5 und früher nicht auf.
| Flash Version | allowDomain | allowInsecureDomain | Mögliche Werte |
|---|---|---|---|
| 5 und niedriger | - | - | - |
| 6 | X | - | Textbasierte Domäne (example.com) |
| 7 | X | X | Textbasierte Domäne (example.com) |
| 8 | X | X | Textbasierte Domäne (example.com) |
| 9 | X | X | Textbasierte Domäne (example.com) |
Die Verwendung von Platzhalter bzw. Wildchars wird erst ab Flash Player 8 und höher unterstützt, wenn eine Flashdatei im Format 7 abgespeichert wird, so haben diese Platzhalter keine Wirkung.
Der Befehl allowInsecureDomain wird erst ab Flash Player 7 und höher unterstützt und stellt eine Erweiterung für allowDomain da, falls die Flashdatei auf einen sicheren (https) Server liegt.
Es wird im allgemeinen dringends von der Verwendung abgeraten, nur wenn man weiß was man macht sollte man diese Funktion verwenden.
Im Grund funktioniert dieser genauso wie allowDomain nur mit den Unterschied, das die Flashdatei auf die zugegriffen wird sich im https Bereich befinden darf.
Eine solche Anfrage würde bei allowDomain abgeblockt werden, da es sich um ein Sicherheitsrisiko handelt.
Beispiel
// Die SWF Haupt Datei liegt auf https://example.com/MainProg.swf
// Kleine neben Dateien liegen auf http://area-network.de
System.security.allowInsecureDomain("area-network.de");
In diesem Beispiel liegt die MainProg.swf in einem sicheren Bereich https://example.com.
Die neben Dateien liegen jedoch auf einer sicheren Domain und sollen auf die SWF Datei im sicheren Bereich zugreifen können.
Ein reines allowDomain würde nicht funktionieren, in diesem Beispiel müsste allowInsecureDomain benützt werden.
Mögliche Risiken von allowInsecureDomain
Folgendes Beispiel, angenommen es gibt einen Webshop der 2 Flashdateien hat, eine für den Shop (shop.swf) welche in einem ungesicherten Bereich liegt und eine Flashdatei für den sicheren Bereich z.B: für den Warenkorb (warenkorb.swf).
Dieser Aufbau ist bei den meisten Shops der Fall, da eine sichere Verbindung teuer und langsamer ist als eine ungesicherte.
Ein Angreifer hätte keine Möglichkeit die Daten im sicheren Bereich abzufangen oder aber auszulesen, da die Verbindung verschlüsselt ist und dies sich nicht so einfach fälschen lässt.
Wenn jedoch allowInsecureDomain in der warenkorb.swf im sicheren Bereich vorhanden ist so kann ein Angreifer die shop.swf manipulieren da diese sich im unsicheren Bereich befindet und kann so Daten von warenkorb.swf auslesen.
Es ist also ratsam das man sich vorher genau überlegt ob es evt. Angriffspunkte gibt, da in der heutigen Zeit leider viel zu weniger darüber nachgedacht wird.
In der Adobe Flash Player Dokumentation findet man die Änderungen im Detail erklärt, es lohnt sich also diese auf jedenfall durchzulesen.
Die meisten Probleme treten auf, wenn eine neue Version erscheint und man sich nicht über genaue Änderungen informiert hat.
