Flash Security at the end of Flash era

Flash era is rapidly wrapping up and it is important to ensure the security of Flash applications we leave behind us.

Danger of crossdomain.xml

crossdomain.xml specifies the following:

  • If https://other-domain.com/evil.swf can read data from your domain https://mycorp.com/user-mail
  • If other crossdomain policies can be found on your domain e.g. https://mycorp.com/relaxed-app/user-supplied-file.csv

If you don’t provide or provide inappropriate https://mycorp.com/crossdomain.xml and some data on your domain is protected by:

  • Cookies
  • HTTP Authentication
  • Other ambient user credential e.g. client certificate

then attacker can steal that data without user even noticing.

Example: 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.

No crossdomain.xml

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 https://mycorp.com/userfiles/!

The safest /crossdomain.xml

Ultimate SWF Security Solution

Delete all SWF that are no longer needed. Every SWF file is a chance for attacker to:

  • Execute attacker-supplied JavaScript by e.g. making your app call navigateToURL(new URLRequest("javascript:alert(1)"))
  • Use SWF as a proxy to make requests to your domain if your SWF calls System.allowDomain()
  • List goes on

Moving SWFs to a cookie-less domain

Moving SWF to a cookie-less domain prevents attacker from making use of:

  • JavaScript injection bugs
  • Security.allowDomain("*") bugs

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.


If https://mycorp.com/mail.swf will execute Security.allowDomain("*") or Security.allowDomain("other-domain.com") then 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.

Learn more

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.

Leave a Reply