|
David,
Please consider this thread
as "usability" posting - just giving you feedback about user
experiences.
I do understand the intent and
the case presented in the documentation. The posting simply indicates the
current status of the model as it appears to a new or other platform developer
who needs crossdomain functionality for external servers in the
application. As such they do not care about LAN access and it would seem a
rather simple task for Flash security manager to identify and make separate case
for intranet zone and local access. That would allow to keep intranet safe
(at much lower performance cost then reading external file) while allowing
client control of external crossdomain access.
As far as behind firewall spying, the second half
of the posting said that DOS, poking and other trojan activity can be done
anyway from AJAX client that can be navigated through fscommand or such. I do
understand the power and danger of socket API opened in Flex 2, and do think
that in order to be utilized properly, the security manager needs to be
extended. However, I am not sure that crossdomain is an adequate answer though -
most likely corporate security services would not be able to support it in
timely fasion needed for development/deployment.
We have been producing
commercial ActiveX for the last 5 years for wide distribution that had to
maintain list of "trusted" servers/domains via custom security manager. That
would be configurable by either end-user, system administrator or being disabled
outright depending on the distribution mode. The same lockdown features for
corporations can be offered in Flash. I did not hear about any issues with
crossdomain security on our control yet.
Sincerely,
Anatole Tartakovsky
----- Original Message -----
Sent: Monday, February 13, 2006 9:53
PM
Subject: RE: [flexcoders] Benefits of
Flash Security Model and crossdomain.xml
Hi,
It has nothing to do with license
validation.
Others have answered this question numerous time on this
list, but this is the first I have heard anyone think it has to do with
license enforcement.
It would be a gaping security hole to not do
this.
_David
IMHO. it does not serve security purposes - the
only thing it can be used for is license validation. Let us say you want to
wrap access to yahoo financial services that has limits on number of free
requests per IP address per day. The only way you bypass crossdomain.xml is
by proxing all the requests through your server as the only way to get the
data. That in turn inforces usual industry licensing requirements - enabling
real data provider identify your server.
I think the documentation has to clearly
identify crossdomain as not security, but license enforcement feature - or
be changed to give control to the client application rather then
server.
Thank you,
Anatole Tartakovsky
PS: DOS attack protection is unlikely as Flash
1.5 uses the same amount of connections that are allowed by the browser
to AJAX (2 by default) and can not be a threat as it offer less control to
the offender then usual HTTPRequest in mxml (Microsoft XML)
parser.
----- Original Message -----
Sent: Monday, February 13, 2006 9:11
PM
Subject: [flexcoders] Benefits of
Flash Security Model and crossdomain.xml
I must be missing something, but I'm a bit
confused as to the design
of the Flash Security Model and
crossdomain.xml.
My main question is who is this model intended to
protect?
As I undestand it, this protects third party servers from
disclosing
their "data" to flash clients. That is, if you do not
have a cross
domain file on a third party server, a flash program
cannot access the
data. But, any other program (e.g. ,a web
browser, socket program,
etc) could easily access this data. It's up to
the client to recuse
itself (and only flash clients recuse
themselves). It would seem for
a server to protect itself, it
would have to enforce the protection,
not the client.
My
expectation was that this was more like a Java sandbox which
prevented
a program from accessing other sites for the protection of
the client,
not the server. In such a scheme one might expect
the
crossdomain.xml file to be controlled by the server which served
the
flash application (not the 3rd party server) ... a chain of
trust.
If it's controlled by the 3rd party, then there's not a huge
amount of
protection.
So I can't see any benefit of letting the
thrid party server be in
control of this file. If the
crossdmain.xml file is to protect the
server, then it misses the case
where non-flash clients can access the
server. If it is to
protect the client from a malicious thrid party,
the third party can
simply add a crossdomain.xml file to their site.
Perhaps this is to
avoid DOS'ing a third party site from a flash app,
but attempting to
grab the crossdomain.xml file could be a form of
attack (although
arguably less intensive).
So what am I missing here?
Perhaps
there are use cases that I don't see that this model affords
protection
either to the client or the
server.
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
