[flexcoders] CSSI Security Issues and Flex
Cross Site Scripting attacks are the bane of web based systems. Essentially an attacker takes advantage of the fact that some text they can enter contains code which is evaluated when someone else looks at the text. For example, a user enters text into a text input field on a web page. Later on an admin user or another user views that info. The text had a hidden javascript command which causes something bad to happen in the context of that other person, not the attacker. For a while I thought flex was largely immune to this. Then I started thinking. One exploit is that fscommands are interpreted by some flex components which accept htmlText. I think this is slightly better than javascript in that it may require a mouse click to get triggered, but still a threat. Another exploit is when the input from Flex is displayed in a web browser (or vice versa). Given that Macromedia owns the platform, they are in a unique position to stamp this problem out at the roots. Macromedia can and should do a better job than the web browser equivalent world (which more/less shrugs responsibility of this matter). Here's one way to resolve the issue. There are a handful of input methods in Flex that allow arbitrary input. It would be a step in the right direction if (by default) these text input methods would strip out offending strings. Ideally there would be a property on these components that would allow them to accept any input ... but by default they would be safe. Alternatively there could be an application level setting that controlled for this. Another idea is to disable execution of fscommands by default and require setting a property on a component before they can be handled. There are many flavors of a solution here. The key issue is that Flex should be a safe environment by default. P.S. It's easy to say that it's the responsibility of each Flex developer to address this. Rather Macromedia spends one week of effort addressing this than each flex development team that is lucky enough to recognize the issue. P.P.S. It's also easy to dismiss the exploit on the grounds that certain knowledge needs to be known or users interaction is involved or that it is unlikely to happen. I'm sure that's what Yahoo thought before their internal systems were attacked Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] CSSI Security Issues and Flex
The title may be a bit of a misnomer, because Macromedia Flex lives on the server, while cross-site scripting exploits would occur on the client machines. This seems a sub-class of general security in the Macromedia Flash Player rather than the development environment, true...? Here's general background info on security and privacy in the Macromedia Flash Player: http://www.macromedia.com/devnet/flashplayer/ ... and here's background on recent security issues in the Macromedia Flash Player: http://www.macromedia.com/devnet/security/security_zone/#flashplayer As I understand the post, you're concerned about the possibility of a command injection into a textfield of a SWF application. (I could be wrong, but it sounded to me more like a script-injection issue than a cross-site scripting issue.) Have you been able to see this happen yet? have you typed fscommand:() into a textfield in a particular component to pop up an alert or such? If there's a recipe that could be reproduced in-house then we can work on it. Or is it more a general curiosity, about whether there might be a way that such a thing is possible? tx, jd -- John Dowdell . Macromedia Developer Support . San Francisco CA USA Weblog: http://www.macromedia.com/go/blog_jd Aggregator: http://www.macromedia.com/go/weblogs Technotes: http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks. Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] CSSI Security Issues and Flex
On 5/5/05, Eric Raymond [EMAIL PROTECTED] wrote: Here's one way to resolve the issue. There are a handful of input methods in Flex that allow arbitrary input. It would be a step in the right direction if (by default) these text input methods would strip out offending strings. Ideally there would be a property on these components that would allow them to accept any input ... but by default they would be safe. Alternatively there could be an application level setting that controlled for this. It would be hard to define offending strings. The way this is solved in the HTML world is, data is encoded at the output end. For example, if a 'title' and 'description' is being output in a webpage, the values for the 'title' and 'description' field are HTML-encoded before printing. So basically the application treats data like data (and prevents it from being treated like code) at the output end. The other approach, of restricting input to a subset, is used when you want users to be able to input some code (B, I, P tags in HTML, but not malicious tags like SCRIPT, OBJECT, etc.) but only specific types of code. Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [flexcoders] CSSI Security Issues and Flex
These are some good points, Ive forwarded this on to our Product Security Team and theyre going to think about this a little more in terms of existing and future Flex components and will make recommendations as to how to lock them down. Matt From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Eric Raymond Sent: Thursday, May 05, 2005 10:45 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] CSSI Security Issues and Flex Cross Site Scripting attacks are the bane of web based systems. Essentially an attacker takes advantage of the fact that some text they can enter contains code which is evaluated when someone else looks at the text. For example, a user enters text into a text input field on a web page. Later on an admin user or another user views that info. The text had a hidden _javascript_ command which causes something bad to happen in the context of that other person, not the attacker. For a while I thought flex was largely immune to this. Then I started thinking. One exploit is that fscommands are interpreted by some flex components which accept htmlText. I think this is slightly better than _javascript_ in that it may require a mouse click to get triggered, but still a threat. Another exploit is when the input from Flex is displayed in a web browser (or vice versa). Given that Macromedia owns the platform, they are in a unique position to stamp this problem out at the roots. Macromedia can and should do a better job than the web browser equivalent world (which more/less shrugs responsibility of this matter). Here's one way to resolve the issue. There are a handful of input methods in Flex that allow arbitrary input. It would be a step in the right direction if (by default) these text input methods would strip out offending strings. Ideally there would be a property on these components that would allow them to accept any input ... but by default they would be safe. Alternatively there could be an application level setting that controlled for this. Another idea is to disable execution of fscommands by default and require setting a property on a component before they can be handled. There are many flavors of a solution here. The key issue is that Flex should be a safe environment by default. P.S. It's easy to say that it's the responsibility of each Flex developer to address this. Rather Macromedia spends one week of effort addressing this than each flex development team that is lucky enough to recognize the issue. P.P.S. It's also easy to dismiss the exploit on the grounds that certain knowledge needs to be known or users interaction is involved or that it is unlikely to happen. I'm sure that's what Yahoo thought before their internal systems were attacked Yahoo! Groups Links To visit your group on the web, go to:http://groups.yahoo.com/group/flexcoders/ To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
