ArticleFlashSecurity - doctype - Introduction to Flash security

Updated Nov 15, 2008 by pilgrim
Labels:	is-article, about-security

ArticleFlashSecurity

Introduction to Flash security

Flash is a broadly-deployed technology, but its security controls are still in their infancy. Unfortunately, both web applications using Flash and web applications not using Flash are affected by insecure design of Adobe's Flash Player.

This section discusses some important pitfalls to watch out for when developing Flash applications, when hosting user-submitted .swf files, and when interacting with Flash applications hosted on other sites.

A brief look at the Flash security model

By default the security model for Flash is similar to the Same Origin Policy. Flash can only read responses from requests from the same domain where the Flash application originated. Flash also places some security around making HTTP requests, but one can usually make cross domain GET requests via Flash's getURL() function. Also, Flash does not allow Flash applications that are loaded over HTTP to read HTTPS responses.

Flash does allow cross-domain communication, if a security policy on the other domain permits communication with the domain where the Flash application resides. The security policy is an XML file, usually named crossdomain.xml and located in the root directory of the other domain. The worst policy file from a security perspective looks something like this:

<cross-domain-policy> 
    <allow-access-from domain="*" /> 
</cross-domain-policy>

The above policy allows any Flash application to communicate (cross-domain) with the server hosting this crossdomain.xml file.

Despite the naming convention, the policy file can reside at any URL, with any name, in any directory. A Flash application can load an arbitrary security policy file with one line of ActionScript:

System.security.loadPolicyFile(“http://www.google.com/crossdomain.xml”);

If it is not in the server's root directory, then the policy only applies to the directory that the policy file is in and all its subdirectories. For instance, say policy file was located in http://www.example.com/sub/crossdomain.xml. Then the policy would apply to requests like http://www.example.com/sub/stuff.html and http://www.example.com/sub/more/stuff.html, but not to pages like http://www.example.com/ or http://www.example.com/admin/.

XSS via Flash applications

The most common cause of XSS is that a vulnerable server does not validate user input, so an attacker can inject HTML that includes malicious JavaScript. However, XSS can also occur through client-side Flash applications, if user input within the Flash application is not properly validated. Finding XSS in Flash applications is arguably easier than on web applications because attackers can decompile Flash applications and find security issues in the source code, rather than blindly testing server side web applications.

While my code currently only applies my workaround policy checking algorithm in a specific subset of cases relevant to the hole I was addressing (where the page-domain and the swf-domain differ), I could quite easily remove that check and my code would effectively "plug" up a good portion of the vulnerabilities to the security file parsing as pointed out in this post.

Thanks for bringing this to light... it's very important and intriguing to examine.

Comment by 5up3rh3i, Jan 07, 2009

http://www.80vul.com/flash/Flash-getURL-XSS-attacks.htm

Comment by peleus.uhley, Dec 02, 2008

The full Flash Player 10 security model is documented here: http://www.adobe.com/devnet/flashplayer/articles/flash_player10_security_wp.html

Adobe also announces upcoming and recent changes to the security model via the security section of the Adobe Developer Center: http://www.adobe.com/devnet/flashplayer/security.html

A brief look at the Flash security model

XSS via Flash applications

Further reading