Socketproblem ab Playerversion 9,0,124,0

[xjjaguar]

moin moin zusammen,

nun ist es Amtlich: Seit der Player-Version 9.0.124.0 ziehen die angekündigten verschärften Sicherheitsrichtlinien bei XML-Sockets.

….Und ich krieg’s einfach nicht gebacken. Seit 2 Tagen quäle ich mich nun durch abstrakte Beschreibungen und endlose Forenbeiträge. Ohne erkennbaren Erfolg.


Aber nun zu dem Problem:

Erste Anforderung ist: Die crossdomain.xml muss am Port 843 zur Verfügung stehen. Also habe ich eine neue Site im IIS eingerichtet, ihr die gleiche IP zugewiesen wie der Site, aus der die SWF geladen wird, und ihr den Port 843 zugewiesen. Dann hab ich noch der crossdomain.xml Serverseitig den http-Header „application/xml“ zugewiesen.

In der FLA habe ich unmittelbar vor dem Zuweisen und Öffnen der Socket folgende Statement hinzugefügt:

System.security.allowDomain("all");
System.security.loadPolicyFile("xmlsocket://123.456.789.012:843");

Die crossdomain.xml hat folgenden Aufbau:

<?xml version="1.0" ?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only" />
<allow-access-from domain="all" to-ports="1043" />
</cross-domain-policy>

In der Firewall musste der Port 843 geöffnet werden.

Das Ergebnis im flashlog:

Warnung: [strikt] Richtliniendatei bei xmlsocket://www.meinedomain.de:843 wird aufgrund falscher Syntax ignoriert. Hinweise zur Behebung dieses Problems finden Sie unter http://www.adobe.com/go/strict_policy_files_de

Warnung: Beim Warten auf die Socketrichtliniendatei wurde bei xmlsocket://www.meinedomain.de:1043 das Zeitlimit erreicht (3 Sekunden). Dies sollte keine Probleme verursachen, Sie können aber eine Erklärung unter http://www.adobe.com/go/strict_policy_files_de finden.

Fehler: Für SWF von http://www.meinedomain.de/test/porttest2.swf darf ohne Richtliniendatei keine Verbindung mit einem Socket in der eigenen Domäne hergestellt werden. Hinweise zur Behebung dieses Problems finden Sie unter http://www.adobe.com/go/strict_policy_files_de


Ich habe die crossdomain.xml 100 Mal geändert. „<?xml…“ raus, statt „master-only“ „all“ gesetzt usw. Das Ergebnis ist zum Verzweifeln immer dasselbe. Ich bin absolut ratlos.

Es muss doch jemand geben, der das Problem schon gelöst hat. Kann doch eigentlich nicht soooo schwer sein.

hiiiiilfe

[xjjaguar]

Hallo zusammen,

Das Problem ist gelöst.

Ich würde sagen, da hat uns Adobe ein ganz schön faules Ei ins Nest gelegt.

Ab der Player-Version 9.0.124.0 ist für die Socket-Prgrammierung ein zusätzlicher Fielserver an Port 843 erforderlich, der die crossdomain.xml verarbeitet. Selbst dann, wenn der Client und Server in der selben Domain liegen.

Der Flashplayer schaut automatisch nach einem Socketserver, der an Port 843 lauscht, und übergibt ihm "<policy-file-request/>\0". Der gibt dann den Inhalt der crossdomain.xml (Kann jetzt auch anders heißen) zurück, der von Flash-player als Policy ausgewertet wird.
Das ist alles. Man braucht im Flashprogramm nichts zu ändern. System.security.loadPolicyFile braucht nicht gemacht zu werden.

Adobe stellt so einen entsprechenden File-Server in Perl und Phyton bereit. Ich habe für Windows-Server einen kleinen Server in VB geschrieben, der diese Aufgabe erledigt. Wer das braucht, kann mich gerne ansprechen.

Bis denne
Achim

[SpecOps-12]

Und dieser ganze Heckmeck wird ab sofort dann immer nötig sein, wenn man ne xml-Datei laden will, und das auch, wenn sie in der selben Domain liegt??

[xjjaguar]

Das einfache Laden von XML-Dateien aus der gleichen Domain soll wohl weiterhin so funktionieren wie bisher, wenn ich das richtig verstanden habe. Aber da lasse ich mich auch gerne eines Besseren belehren.

Das Problem ist aber das Aufbauen einer XML-Socket-Verbindung (z.B. für Chat oder Spiele). Da war bisher aus der gleichen Domain ohne Probleme möglich.
Jetzt geht das nur noch mit besagtem Policy-File

[tux]

super tolli toll....

ich habe momentan exakt das gleiche problem bei einer flex intranet
applikation, welche auf einem anderen intranet server auf webservices
zugreift.
was für ein herrlicher dreck, wenn es um das updaten von rechnern
in produktivumgebungen geht (flashplayer bei clients)....


habe ebenso versucht, das policyfile nach den tips von adoofe zu
tunen, jedoch ohne erfolg...

PHP-Code:

<cross-domain-policy>
<site-control permitted-cross-domain-policies="all">
 
    <allow-access-from domain="http://meinedomain"></allow-access-from>
    <allow-http-request-headers-from domain="http://meinedomain" headers="*"></allow-http-request-headers-from>

  </site-control>
</cross-domain-policy> 


PHP-Code:

Fehler: [strikt] Richtliniendatei bei http://domain/crossdomain.xml wird aufgrund falscher
Syntax ignoriert. Hinweise zur Behebung dieses Problems finden Sie unter
http://www.adobe.com/go/strict_policy_files_de
*** Security Sandbox-Verletzung *** 


wie kann ich denn nun deinen lösungsansatz verstehen, respektive
hast du links zu den dementsprechenden infos von adobe?

oder eventuell irgendjemand ad hoc nen anderen tip?

thx

[xjjaguar]

Die letztendliche Bestätigung, dass ein zusätzlicher Socketserver erforderlich ist, um das Policy-File zu laden, hab ich hier gefunden

http://www.adobe.com/devnet/flashpla...icy_files.html

Da werden auch 2 Server (Perl und Phyton) zum Download angeboten. Da kannste nur auf Windoof-Server nicht ohne Weiteres mit anfangen. Deshalb hab ich mir einen eigenen Server gebastelt, der als Exe unter Windows läuft.

[tux]

scherz beiseite...

egal welche "ehrenhafte" sicherheitsintention adobe da hat, aber der
impact ist ja gewaltig...haben die eigentlich nen schaden da?
ich könnte mich derartig aufregen gerade....

ich wandere also jetzt zu unserer IT und erzähle den globalen admins,
das sie sich mal bitte um diesen quark kümmern sollen, oder was?
wir befinden uns hier gerade in einer etwas heisseren phase eines
projektes, welches eigentlich kurz vor golive steht. wenn irgendjemand
in diesem moment den drecksplayer updated, weil sein rotzwindowsrechner
samt ie / ff aus irgendeinem grunde den flashplayer crashen (alles schon
erlebt), dann is hier aber echt rambazamba auf dem dampfer....

kann natürlich sein das ich übertreibe und den sinn nicht verstehe...
tschuldigung...


lustig übrigens:
mit dem modifizierten policyfile kann ein älterer player nicht mehr
zugreifen. habe jetzt wieder das alte teil genommen...
bedeutet das im umkehrschluss keine heterogene flashplayerverteilung?

[xjjaguar]

Na logisch arbeiten die alten Player nicht mit der geänderten Datei. Die neuen aber auch nicht

Adobe sagt ganz klar: keine HTTP-Policy-Files mehr. Die werden in Zukunft igniriert.

Also nützt ein Ändern der jetzigen http-files gar nix. Die alten Player können mit der geänderten Sytax nix anfangen und die neuen lesen die Datei garnicht erst.

Hier noch mal ein interessanter Artikel einer Ankündigung:

http://www.zdnet.de/security/news/0,...9188797,00.htm

Man achte mal auf das Datum.
Ab den 8.April haben die schon "scharf geschossen"

Ineressanter Weise konnte ich feststellen, dass offensichtlich auch ab der Version 115 die neue Methode verwendet wird, aber wohl erst seit 124 zum Fehler führt. In den letzten 2 Stunden wurden über 100 Verbindungen über den neuen Socket-Server hergestellt, ob wohl sich in den letzten Tagen vielleicht 10 Kunden beklagt hatten, dass sie nicht mehr reinkommen.
Man kann also damit rechnen, das man in den nächsten Wochen viele Kunden aussperrt, wenn man nicht reagiert.

Müssen die Adobe-Entwickler morgens eingentlich Zwecks Drogentest zur Urin-Probe

[Gnut]

Verdammt, ich hab's erst heute gemerkt, dass alle Users mit dieser FlashPlayer Version nicht mehr auf meinen Server zugreifen können.

Jetzt muss man noch extra einen FileServer schreiben.

[xjjaguar]

Mit dem Fileserver an 843 ist das Problem bei mir nur teilweise gelöst.

Zwar kommen die User jetzt wieder auf den eigentlichen Server, aber die Policy hat für die Lebenszeit des Clients bestand. Wenn die Policy aber nicht innerhalb von 3 Sekunden vorliegt, hat sich der Zugriff generell erledigt. Das passiert zwar nur selten, aber es passiert.

Ich dachte mir, die Policy explicit vor dem Connect generelle noch einmal zu lesen.

System.security.loadPolicyFile("socket://www.meinedomain.de:843");		
mysocket = new XMLSocket(); 
mysocket.onConnect = myonconnect;

Aber das explizite Lesen scheint vollkommen ignoriert zu werden.
Der User muss dann das Client-Fenster komplett schließen und neu aufrufen. Das ist unzumutbar.

Oder hab ich das was übersehen?

[Gnut]

hmm... wir brauchen nen netzwerktraffik-verzögerer zum testen

kennt jemand einen?

[xjjaguar]

Problem ist nun endgültig gelöst.

das musste natürlich xmlsocket://..... heißen.

Jetzt klappt's auch, wenn die 3 Sekunden beim impliziten Lesen der Policy überschritten wurden.

Man, man... so viel Zeit reingebuttert, nur damit es nach dem neuen Player-Release wieder so läuft, wie es schon seit 7 Jahren problemlos funktioniert hat.

Naja. Was soll's... Könnt ja sonst langweilig werden

[blemmo]

Hallo,

der Thread hier hat mir schonmal sehr viel geholfen, Danke an die Beteiligten. Leider erhalte ich immernoch die "aufgrund falscher Syntax ignoriert" Meldung, obwohl der Policy-Server läuft. Hat jemand eine Idee, wie ich dem Problem auf die Spur kommen kann?
Die xml Datei (bereits xmal geändert, im Moment sehr basic):

PHP-Code:

<cross-domain-policy>
  <site-control permitted-cross-domain-policies="master-only"/>
  <allow-access-from domain="mytld.de" to-ports="###"/>
</cross-domain-policy> 


Ich habe das Perl-Skript für xinetd von Adobe benutzt. Wenn ich den Test durchführe

PHP-Code:

perl -e 'printf "<policy-file-request/>%c",0' | netcat 127.0.0.1 843 


wird das XML ausgeliefert.
Port 843 ist auch offen, ich kann z.B. mit meinem Browser verbinden, was zu einer langen Anfrage führt, die Verbindung wird also hergestellt.
Im xinetd-Log sehe ich solche Einträge:

PHP-Code:

08/5/5@12:35:49: START: flashpolicy from=xxx.xxx.xxx.xxx
08/5/5@12:35:49: EXIT: flashpolicy status=0 duration=0(sec) 


also scheint der Server ja auch etwas zu tun.

Trotzdem mag Flash nicht die Socketverbindung erlauben. Hat jemand eine Idee, was ich noch testen kann?

[blemmo]

Nachtrag: mit dem Standalone perl-Skript und der gleichen XML Datei funktioniert es. Also scheint das Problem mit dem xinetd-Skript zusammenzuhängen? Hat jemand damit schon Erfahrungen gesammelt? Würde schon gerne den Server als xinetd-Service laufen lassen...

[blemmo]

oh Mann... mein xinetd ist so konfiguriert, dass er auch die Fehlermeldungen an den Socket schickt. D.h. alle Debug-Infos nach STDERR in dem Perl-Skript wurden zusammen mit dem XML gesendet. Klar dass Flash das nicht mag, und auch dass nix in den Logs ankam... *d'oh*.

naja, jetzt weiß ich warum Adobe sagt die Skripts sind nicht für den produktiven Betrieb geeignet...