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/
