Currently, there are 4 kinds of Security Sandbox for swf file. They are:
- Security.REMOTE – SWF file from Internet URL, following domain sandbox rules;
- Security.LOCAL_WITH_FILE – SWF file from local which can get local data but cannot communicate with internet.
- Security.LOCAL_WITH_NETWORK – SWF file from local which can communicate with internet but not local data
- Security.LOCAL_TRUSTED – SWF file is local file but has been set as trusted file which can communicate with local as well as internet. This kind model has highest authority, when we testing flash file using flash tool, we are under this kind of model.
There are two basic rules for those Security Sandboxs:
There are two things we have to go through if we are talking about Flash Security Sandbox:
The function of crossdomain.xml
When SWF file try to access resource from remote website, and find:
There will be SecurityError happen during the running of SWF;
What will be crossdomain.xml look like?
If some website using the crossdomain.xml file like above, it means the resource on this website is accessible by any SWF from remote.
If we don’t want the resource be accessed by anyone, we can set the specific website we allow.
For above setting, we allow our resource only be accessed by adobe.com (includes its sub-domain, like http://www.adobe.com; http://test.adobe.com; http://music.adobe.com etc.); then when a SWF file from apple.com want to access our resource, it will fail and got a security error (Oops, sorry, you are not from adobe. You cannot access our resource)
The function of Security.allowDomain
Security.allowDomain authorize the script accessibility for crossdomain file.
For instance, if in b.swf, has a script like:
It means when b.swf is loaded by a.swf, a has full access to b’s script and resource while b has no access to a’s; unless, a.swf also has a script like:
Then b.swf is authorized the accessibility to a.swf
If a SWF file has a script like:
It means any file from different domain can access to that SWF’s script and resource;