RE: Comments on: Access Control for Cross-site Requests

On Wed, 2 Jan 2008, Close, Tyler J. wrote:
> 
> > returning particular content, which is how, e.g., Flash's "magic file" 
> > security mechanism was compromised (with dire consequences).
>
> Could you provide a link?

http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html


> This might be a case of "swallowed the spider to catch the fly". I don't 
> think we should be making this protocol more complex in an attempt to 
> compensate for a poor configuration interface in some HTTP servers.

I think that we must. :-)


> > I don't really understand what you think the current model can't do 
> > that your proposals can.
> 
> Just "be simple". We only needed the client and server to agree on a 
> single bit: "Do you understand the Referer-Root header?"

No, we need more than that.

We need something that (in no particular order):

 * introduces no new XSS attack vectors when a user changes client, 
   assuming the client is conforming to the new spec

 * introduces no new XSS attack vectors when an author changes server,
   assuming the server is conforming to the new spec

 * can be implemented without changing the actual server software

 * can be used to provide files for cross-domain access via GET without 
   scripting of any kind of the server side

 * can be configured on a per-resource basis

 * can be configured without coordination with the main site administrator

 * does not introduce the risk of caches inadvertently allowing access 
   when it should not be allowed

 * leaves the control in the hand of the server

The currently proposed solution achieves all of this, by making the server 
make the decision, but requiring that the decision be conveyed using a 
handshake that explicitly reports the decision, and making that handshake 
expressive enough that it can be precomputed and stored within the 
resource itself, allowing it to be used without server-side scripting.

Your proposals so far have only achieved simplicity by not addressing some 
of the other requirements.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 3 January 2008 00:58:38 UTC