Re: [AC] Helping server admins not making mistakes

On 2008-05-13 16:58:16 -0700, Jonas Sicking wrote:

> First of all it is very possible that the server itself, or the
> scripts running on the server, performs actions that the server
> administrator is not aware of. For example an administrator might
> not realize that the server supports the PUT action such that
> other sites can't just POST to a CGI script, but also replace the
> script using PUT.

If that was the case, the web application in question would be in
*very* significant trouble with or without cross-site requests --
since anybody who could gain access to the user's cookie information
would be able to replace the web application.

Of course, this is just one example, but I'd like to understand
better what security assumption about cross-site requests,
specifically, you want to protect here.

In my view, we should leave generic "bad things can happen when this
HTTP request is sent" scenarios out of scope, and focus on the
specifics of cross-site requests.

> Access-Control-Extra-Headers:
> This header contains a whitespace separated list of headers that the servers 
> wants to allow the requesting site to set. This can be both standard 
> headers, as well as custom headers.
>
> Access-Control-Methods:
> This header contains a whitespace separated list of HTTP methods that the 
> server wants to allow the requesting site to use. This can be both standard 
> methods, as well as custom methods.
>
> Both these lists will be stored in the "method check result cache" (btw, 
> that name sounds odd since it's not a method-check, but rather an 
> access-check).

Assuming this proposal was accepted, we'd be getting to a point
where the combination of Vary, policies, and a ton of headers can
lead to an almost arbitrarily complex matrix that encodes the
decisions, and is cached on the client.

I'd propose to *either* define a policy language that takes these
additional degrees of freedom into account, *if* they are really
needed.  *Or*, lets' go away from the policy language, and try to
model the scope of authorization for the specific client-server
pair.

In other words, my main concern with your proposal is that the model
for XHR2 + access-control becomes ever more complex and messed up.
I'd like to avoid that, as this complexity by itself is likely to
cause trouble.

> Note that this proposal is much simpler than the old syntax we
> used to have where the methods were listed as part of the
> Access-Control header since the syntax is much simpler, and
> neither header is part of the key to the "method check result
> cache" but rather stored as values in it.

... with the downside of making things even more difficult to
understand.

Therefore, please explain in more detail how this is useful.
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 16 May 2008 21:48:26 UTC