The reason why I ask is that I'm telling a vendor of ours they have to use the MS AntiXSS library with the ASP.NET UI components they make, but they also work with Flex to build Flash based UIs - and I was wondering if there's an equivalent for Flash (assuming it's vunerable).
+2
A:
If I understand correctly...
ASP.NEt is used to make web pages, and all UI Components they make will be running in a browser as HTML / JavaScript. Is that correct?
If that is the case, I can understand why preventing cross site scripting would be important in that case.
With Flex (which runs in the Flash Player), everything is compiled down into a binary file, called a SWF. Most of the time, the SWF runs inside the Flash Player, which runs in the browser as a plugin. There would be no way to hack an individual Flex component using XSS.
I don't believe the code you write needs to be protected from cross site scripting. Your biggest fear is player vulnerabilities, which you don't have much control over.
None of this should be a reason not to validate user input.
www.Flextras.com
2010-10-07 23:03:06
@Flextras - Your assumptions regarding ASP.NET are correct. So in essence there aren't any mitigations I should be specifying regarding parsing user input from a *security* perspective(?)
Adrian K
2010-10-08 00:02:00
@Adrian K . In terms of XSS I can't imagine how it could be done w/ input in the flash Player. Since ActionSCript is compiled; it is difficult (if not impossible) to try to get the Flash Player to execute AS3 at runtime (the same a browser may run JS 'on the fly'. I wouldn't worry about that. However, scrubbing data for SQL Injection attacks as part of your remote service call seems like a good idea.
www.Flextras.com
2010-10-08 01:08:50
I think some parts of this answer are not correct. SWFs are not precompiled binaries, exactly, the code is compiled to intermediate bytecodes like Java, which are JITted at runtime. But more importantly, SWFs can read in and execute content from other (possibly malicious) sites. Thus, any time flash's security settings are relaxed (which is often useful or necessary), there is definitely the possibility of XSS attacks. See the link in my answer for more detail.
fenomas
2010-10-08 10:30:14
@fenomas Your answer has a very good point about loading external assets. However, I find it hard to believe anyone would argue about whether or not Flex is compiled. The Flex code I write is Text/ASCII; and the Flex **Compiler** turns it into a binary SWF. If that isn't compilation, I'm not sure what is.
www.Flextras.com
2010-10-08 12:35:23
Whether intermediate bytecodes count as "compiled" or not is a matter of terminology - the issue here is that the "compilation" step doesn't make Flash content any more (or less) safe from XSS attacks.
fenomas
2010-10-09 07:02:06
Flextras, whether intermediate bytecodes count as compiled or not is a matter of terminology - people seem to argue about the exact definitions. All I'm saying is that Flash's compilation step doesn't make Flash content any more (or less) safe from XSS attacks.
fenomas
2010-10-09 07:14:42
@fenomas Your original comment said parts of my answer were wrong, and you highlighted compilation as the source of my error. I assume you also downvoted it. The original question was about components; and because they are compiled, Flex Components are not exposed to XSS vulnerabilities, like a JavaScript/HTML component is. Components, content, and applications are quite different in that regards.
www.Flextras.com
2010-10-09 17:38:31
Yes, the claim you're making here is what's incorrect. Using flash components can certainly expose XSS vulnerabilities, depending on how they are loaded in or embedded, and on what security settings you do or don't change. The general outline of how such attacks occur is described in the article I linked.
fenomas
2010-10-10 02:46:29
I think you're mistaking "Applications" and "Components". Components cannot be loaded or embedded into an HTML page, without first being compiled into a Flash Application. You should take steps to protect your application (as your answer stated), but there is nothing to do at the component level.
www.Flextras.com
2010-10-10 12:58:13
+1
A:
The short answer is: the Flash player has a lot of features in place to prevent XSS attacks, but they're built in to the player itself, so there isn't any particular library you need to use. If you don't call any security-related APIs, and don't put config files on your server, then security-wise, you are already using the most restrictive settings available. (Assuming you also pay attention to how you make use of user input.)
More generally, APIs that have the potential to lead to XSS vulnerabilities are as a rule disabled in XSS situations unless you actively enable them. For example, if an HTML page on your site loads in a flash file from another site, and that flash content tries to, say, make javascript calls into your page, those calls will be blocked by default unless you allow them. Similarly, if flash content on your site loads in components from another site, those components will not be able to introspect into their parent unless you call APIs to allow them to. There are also various restrictions on what happens when another site tries to load in Flash content from your site without your having allowed it.
For all the details, I highly recommend this excellent overview:
With all that said, since you also asked about sanitizing user inputs, it's worth noting that since AS3 has no equivalent of an eval command there is never any question of user input being executed as script. However, any user input that relates to content being loaded could be a vector of XSS attack. (For example, if you append a user-input string to a URL you then load, the user could cause your site to load in their malicious SWF.) But such a case is no different from a situation where you load in a benign 3rd-party SWF, and someone later replaces it with malicious content. Hence in context of Flash, protecting against XSS attacks is not so much about sanitizing user input as it is about making sure that externally loaded contents are not granted permission to run as if they were locally trusted.
And further, since it's often useful or necessary to relax the default restrictions if you want to do something interesting with 3rd-party content (like flash avatars, components, or even banner ads), in those situations it's important for the site admin to understand what they are allowing, and how to prevent the relaxed restrictions from exposing a vulnerability.
fenomas
2010-10-08 05:45:44