security changes in Flash Player 8
This is a very serious issue regarding the new Flash Player 8 security sandbox.
The question is:
I recently switched an "in browser" kiosk app to flash8 and was surprised to see that my main swf that was loaded in the main html page was no longer able to load the interface assets located in a second .swf file.
When the app was running in player 7 there were no problems doing this action.
When the app was running in flash 8 but was exported for player 7 the "security warning" popped up and the user had to go to MM's site to mark the file as "trusted".
When the app was exported for player 8 and running in player 8 there was no warning and the assets wouldn't load.
My lucky break was that I was using a master .exe file (converted from a .swf) that was initializing the entire app. So after a lot of diggin trough this article I found out about the top secret .cfg trust files that were created by the MM security interface on the user's computer. Those files are used to declare the folders on the computer that are fully trusted (to access the net and local resources).
MM official stand on this is that if a user allows a .swf to access both resources or runs a .exe that does this then he knows that the content in discussion can be trusted.
My opinion is that although that's not the case this solution is a good enough compromise between the needs of developers and those of the security of the user. The best illustration of the new security is on this page and you can clearly see the tightness of the "remote loading" scenario (last colum to right). Lots of red cells and only "remote loading remote" allowed.
So if u want to make cool standalone apps either u wrap them using a swf_To_exe (screenweaver is a good free os solution) or you write a nice tutorial about creating and properly locating .cfg files.
The question is:
how can a flash movie loaded from a non-local url (http://) read files from a local path?The answer so far seems to be that it can't:
Loading restrictions: SWF and HTML content from non-local URLs may no longer load any content (SWF, HTML, PNG, and so on) from local paths.I personally am not currently bugged by this issue but other people are. And are also bugged by the vague responses from MM officials. I got one of those as well on FlashCoders. But I think that the evasive replies are intendet for avoiding a straight result on google so that anyone finds out easy about the glitch. The article is 9 pages long and not easy to digest but it's worth reading.
I recently switched an "in browser" kiosk app to flash8 and was surprised to see that my main swf that was loaded in the main html page was no longer able to load the interface assets located in a second .swf file.
When the app was running in player 7 there were no problems doing this action.
When the app was running in flash 8 but was exported for player 7 the "security warning" popped up and the user had to go to MM's site to mark the file as "trusted".
When the app was exported for player 8 and running in player 8 there was no warning and the assets wouldn't load.
My lucky break was that I was using a master .exe file (converted from a .swf) that was initializing the entire app. So after a lot of diggin trough this article I found out about the top secret .cfg trust files that were created by the MM security interface on the user's computer. Those files are used to declare the folders on the computer that are fully trusted (to access the net and local resources).
MM official stand on this is that if a user allows a .swf to access both resources or runs a .exe that does this then he knows that the content in discussion can be trusted.
My opinion is that although that's not the case this solution is a good enough compromise between the needs of developers and those of the security of the user. The best illustration of the new security is on this page and you can clearly see the tightness of the "remote loading" scenario (last colum to right). Lots of red cells and only "remote loading remote" allowed.
So if u want to make cool standalone apps either u wrap them using a swf_To_exe (screenweaver is a good free os solution) or you write a nice tutorial about creating and properly locating .cfg files.
posted by cosmin at 3:08 PM
3 Comments:
Security topic in Flash player is a hot issue and unfortunately there is nobody within a company (and we embrace 6 Flex developers (converted from Flash) already) to talk with about those issues.
I refer here also to your old post to Flashcoders from January 2004
http://chattyfig.figleaf.com/pipermail/flashcoders/2004-January/102254.html
I am also wondering why Standalone player has no Flash player sandbox restrictions imposed and local SWF movie run in Standalone player can access remote Flash SWF and remote data sources (via Flash remoting)
I think I was a little wrong with that statement in the flashCoders post. At that time flash (player 6 as I recall) security was new for me also and my question went unanswered anyway.
The basic idea is that now with flash 8 the standalone player is restricted either to loading local data or to loading web data. You have the option in the export settings. So it can't read local xml and send it to a net server. Unless you specifically allow that in the security settings panel.
The problem with remoting is different because of the fact that the idea of "services" bends towards openess and that you can easily control the access to your services on the server side. If you don't want to allow access to your services from the standalone player you should implement authentification based on checking the swf _url property and match that with your deployment domain. But still the swf could be decompiled, the service address stolen and used in a newly created swf to access the service. So you have to do standard user auth on the server in the end anyway.
But I agree that the remoting calls from the standalone player should be restricted somehow. There is flashGateKeeper for java but it addresses the issue of restricting the classes that can be called and not the source of the calls.
It actually all depends on the system configuration and from there you figure out the security holes and the sollutions that can be implemented.
Doesn't Flex Enterprise Services have some kind of solid auth system anyway?
Dear Cosmin, thank you for the quick answer.
You were talking in January 2004 about Flash MX 2004 (Flash 7), I believe.
You even received an suggestion@Flashcoders to degrate to Flash 6 if you want to load images from remote URL http://chattyfig.figleaf.com/pipermail/flashcoders/2004-January/102258.html
Release data of Flash MX 2004 was 8/25/2003
http://reviews.cnet.com/Macromedia_Flash_MX_2004/4505-6445_7-30521343.html
Thank you for the link for flashGateKeeper. In my understanding this tool is targeted to be used along with Flash MX Remoting.
Macromedia Flex has a special "flex-config.xml" file where all server resources that are planned to be accessed via Flash remoting are listed in named white-list.
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_19251
Post a Comment
<< Home