Flash era is rapidly wrapping up and it is important to ensure the security of Flash applications we leave behind us.
crossdomain.xml specifies the following:
https://other-domain.com/evil.swfcan read data from your domain
- If other crossdomain policies can be found on your domain e.g.
If you don’t provide or provide inappropriate
https://mycorp.com/crossdomain.xml and some data on your domain is protected by:
- HTTP Authentication
- Other ambient user credential e.g. client certificate
then attacker can steal that data without user even noticing.
https://mail.mycorp.com allowing all everybody access it. Then if I just embed invisible SWF on kachurovskiy.com homepage and make it load
https://mail.mycorp.com then I’ll get all your mail without you even knowing about it.
Overly broad crossdomain.xml
If your crossdomain.xml contains
<allow-access-from domain="*"/> then you’re in trouble unless your domain serves only public data. Same stands true for allowing untrusted domains or domain that allow user-controlled data to be served from them.
If you don’t have
/crossdomain.xml malicious SWF can ask Flash Player to load crossdomain policy from
https://mycorp.com/userfiles/vasily.txt on your server and gain access to all URLs under
Ultimate SWF Security Solution
Delete all SWF that are no longer needed. Every SWF file is a chance for attacker to:
- Use SWF as a proxy to make requests to your domain if your SWF calls
- List goes on
Moving SWFs to a cookie-less domain
Moving SWF to a cookie-less domain prevents attacker from making use of:
You can still allow SWF to interact with main domain by allowing that particular domain, see for example YouTube’s crossdomain.xml, just double check that you’re not using
Security.allowDomain() at the same time.
https://mycorp.com/mail.swf will execute
https://other-domain.com/evil.swf will be able to load your SWF and access all it’s content, variables and methods. It’s likely to give
evil.swf access to all the information and actions available to
mail.swf and in general to
https://mycorp.com which may be problem as you already know.
The safest solution is to remove all
Security.allowDomain() calls or at least get a really good understanding what you are allowing by calling this method. This is especially true for AS 2.0 since it has content loading method attached to the display tree.
Hosting user files
This is not really related to Flash but is too often overlooked. There is a very good reason why all Google products serve all user supplied content from separate domains e.g.
googleusercontent.com. Find out why.
This is just a quick overlook of common Flash-related security issues that is intentionally short so that you don’t fall asleep reading.
This post is powered by book The Tangled Web – awesome and rewarding reading for Web Developer.