These are some good points, I’ve
forwarded this on to our Product Security Team and they’re 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:
[email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Raymond
Sent: Thursday, May 05, 2005 10:45
AM
To: [email protected]
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
|
