[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Building in security

From: strk
Subject: Re: [Gnash-dev] Building in security
Date: Wed, 2 May 2007 13:30:23 +0200

The same-domain/cross-domain policy is there to face this situation:

We have host A and B behind a firewall.
B is an application server, A is a client.
Network administrator wants A to be able to access B services, but
only trough trusted applications.

Trusted applications are marked as domain from which the application
has been loaded. So, for instance, if A plays a movie downloaded from B
it gets access to B services, while if A plays a movie downloaded from C
(an external host) it does not.

This configuration is put in a crossdomain.xml file on the host from
which the load is attempted. So, for instance, if B webmaster is willing
to provide the services to movies downloaded from D (another external host)
can do so by writing D domain in the crossdomain.xml file.

To summarize up, loads from a domain/uri are only allowed if the publisher
of that domain/uri *explicitly* allow so by using a crossdoomain.xml file
*or* if the accessing movie has been loaded from the same domain.

Now, this has, in my opinion, the following problems:

(1) Fascist default

  Implicit configuration (ie: no crossdomain.xml file is found) is NOT allowing
  loads by any movies expect the ones downloaded by this host.
  This means that anyone willing to provide their resources publically (say FSF 
  needs to add a crossdomain.xml file, or they'd be practically forbidding 
  by foreign flash movies.
  I'd rather *only* use crossdomain.xml file if actually found on the host, like
  it is for the robots.txt file (ie: be kind if someone asks you).

(2) Security enforced by trusted player

   This whole model only works if you trust the player. A saner implementation 
   use authenticated access to services instead.

Comments welcome.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]