[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnash-dev] crossdomain policy (was: default load policy in gnashrc)
From: |
strk |
Subject: |
[Gnash-dev] crossdomain policy (was: default load policy in gnashrc) |
Date: |
Mon, 20 Nov 2006 18:01:39 +0100 |
To help discussion, I'll try to summarize the problem as I understood it.
Consider the following scenario:
A: web_server
B: intranet_client
C: intranet_server
Assume that host C *trusts* host B (ie: allow http access from B)
Assume that host C does *not* trust host A (ie: not accessible from
outside the intranet)
The problem, as described to me in the past, is that host A can
exploit a denial of service on host C by using the Flash Player
on host B as a trojan horse.
Basically host B plais a movie found on host A, and that movie request
loads from C.
Now, the flash player is NOT the only player able to act as a proxy.
You can do the same thing with JavaScript, and Java, right ?
This means that delegating the security to the software on host B is
pretty tricky, and of course it assumes you have control over the software
installed on B, and it's integrity.
Anyway, let's assume you DO have control over software on B and that
you choose what software to use based on its ability to help you in
this situation, that is you want the software on B to be able
to actually use services on C but only when the request for that
service is originated by a "trusted" software (be it a Java, JavaScript,
Flash or whatever other downloadable and executable software).
So, you want to allow B loading something from C and *that* something
able to access a service on C; but you don't want to allow B loading
something from A and *that* something access service on C.
In a schematic form, your need is:
allow: B (using C-provided application) access C
deny : B (using A-provided application) access C
This could still be implemented by making the C-provided application
contain an 'authentication token' that enables access to service on C.
But this will again requires that the C-provided application is NOT accessed
by A, which would still be possible if accessed tough B. But how would A
know the location of the C-provided application ?
The crossdomain.xml architecture, on the other hand, does not rely on
"security trough obscurity", in that even if A knows exact location of
things on C, the player on B won't allow access to it unless explicitly
allowed by C configuration (a file on its root).
Maybe gnash could implement this after all, but only on a condition:
"Gnash user must be able to *disable* it"
I mean, we don't want Gnash to forbid access to *anything* unless that
is really the Gnash user intention (see blacklist).
Other thoughts ?
--strk;
- Re: [Gnash-dev] default load policy in gnashrc, (continued)
- Re: [Gnash-dev] default load policy in gnashrc, strk, 2006/11/20
- Re: [Gnash-dev] default load policy in gnashrc, Tomas Groth, 2006/11/20
- Re: [Gnash-dev] default load policy in gnashrc, strk, 2006/11/20
- Re: [Gnash-dev] default load policy in gnashrc, Rob Savoye, 2006/11/20
- Re: [Gnash-dev] default load policy in gnashrc, strk, 2006/11/20
Re: [Gnash-dev] default load policy in gnashrc, Rob Savoye, 2006/11/20
Re: [Gnash-dev] default load policy in gnashrc, strk, 2006/11/20
Re: [Gnash-dev] default load policy in gnashrc, Rob Savoye, 2006/11/20
[Gnash-dev] crossdomain policy (was: default load policy in gnashrc),
strk <=