Re: [flexcoders] Re: CSSI Security Issues and Flex (Proof of concept exploit)
Eric Raymond wrote: > Here is a sample exploit. It requires you to trick the user into > clicking a "link". But if you can do that some percent of the time, > with the aid of a flash decompiler to explore the app, you might be > able to do all sorts of interesting things. Thanks, Eric. I suspect one of my partners may already have forwarded this along to the Security Center silently, without an acknowledgment to the public conversation, so I won't put a lot of time into this here myself. But it almost sounds like you're describing a situation of "evil author", rather than "evil site visitor", because you listed MXML rather than text which a visitor could type into a field for a classic script-injection approach. (And even then, "asfunction()" calls would be bounded by the same security sandbox which corrals all ActionScript calls.) Hmm... or maybe your scenario is closer to "I relied on some type of web service which went rogue behind my back", that might be it...? But I'd defer to the Security Team... if you haven't received an offlist advisory that someone sent this there for you already, then here's the "Please alert us" entry: http://www.macromedia.com/devnet/security/security_zone/alertus.html 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/
[flexcoders] Re: CSSI Security Issues and Flex (Proof of concept exploit)
Two more points: 1) With a small number of ways to accept input and complete control over the client implementation, Macromedia can plug this hole on the client side. 2) But fixing things one the client may not prevent attack if the one were to bypass the client in some way. The flex proxy/remote objects makes that a bit more difficult but not impossible. One could generate a post directly to the web service via a browser or other tool. This is analogous to performing input validation only in javascript and not on the server side. Is this a last point an argument for throwing our hands up in the air and not doing anything (even if it's not complete)? I don't think so IMHO, having the four or five input methods in Flex by default disallow entry of asfunction and possibly "<" and ">" (or map them to something like "[" and "]") would be a small step towards safety for the masses. Perhaps this would be turned off automatically on "password" input. So much for beating a dead horse 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/
[flexcoders] Re: CSSI Security Issues and Flex (Proof of concept exploit)
Semantics aside, flex applications tend to promote a type of interaction that the majority of flash applications (in general) do not. FYI, I mispoke hugely. The offending command is asfunction, not fscommand. Here is a sample exploit. It requires you to trick the user into clicking a "link". But if you can do that some percent of the time, with the aid of a flash decompiler to explore the app, you might be able to do all sorts of interesting things. http://www.macromedia.com/2003/mxml"; xmlns="*"> --- In flexcoders@yahoogroups.com, John Dowdell <[EMAIL PROTECTED]> wrote: > 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/
