Re: [AC] Helping server admins not making mistakes

Thomas Roessler wrote:
> 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.

While it's true that servers need to be prepared for any type of HTTP 
requests already, access-control makes it possible to do them using 
other users peoples credentials.

So while we don't need to worry about "bad things happen when this HTTP 
request is sent", we do need to worry about "bad things can happen when 
this HTTP request is sent by a user with root credentials".

Getting access to a users cookie information is no small task. If you 
can do that you can most likely also steal all the users money, read all 
his email, and ruin his reputation by messing up their blog and facebook 
page.

>> 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 don't think this adds that much complexity to be honest. First of all 
Access-Control-Extra-Headers is likely rarely going to be used. In most 
cases there will be no need to set custom headers. In fact I would 
happily remove the ability to set headers from the first version of 
Access-Control. Other than the small set on the white-list.

Access-Control-Methods is worse as it would fairly often have to be used.

However I'm not sure I agree that the "matrix" is getting very big here. 
In fact, I would argue that these headers make the matrix much smaller. 
The matrix that server authors have to worry about is the matrix of the 
possible requests Access-Control enables. As it currently stands the 
server operator have to worry about a very big matrix, i.e. the full set 
of possible headers, and of possible methods. These new proposed headers 
can only reduce that matrix.

> 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.

I'm not quite following here. Please elaborate.

> 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.

My concern is the people that do want to use Access-Control for 
cross-site data transfer (anyone else is of no concern since they won't 
opt in).

These people will have intimately know how the server reacts to the full 
set of possible headers and of possible methods. I've certainly never 
known that for any of the servers where I've put content.

The smaller portions a server opts in to, the smaller the risk that they 
accidentally opts in to something where they accidentally shoot 
themselves in the foot.

/ Jonas

Received on Wednesday, 28 May 2008 01:13:00 UTC