Re: [access-control] non-GET threat model and authorization choreography

On Mon, 15 Oct 2007, Anne van Kesteren wrote:
> 
> For a non-GET access request you look up in the access method check 
> cache whether you can make the desired non-GET to the URI. If the access 
> method check cache doesn't have an entry for the given URI you make an 
> access method check request to URI. An access method check request is a 
> GET request that includes a Method-Check HTTP header that indicates the 
> desired HTTP method. You do a match against the response Allow header 
> method list and if there's a match (case-sensitive comparison as per 
> HTTP) and the response also includes Access-Control / <?access-control?> 
> stuff that allows access you do a subsequent request to the URI with the 
> non-GET method.
> 
> If the response to the access method check request also includes an 
> Method-Check-Expires HTTP header that is valid and contians an HTTP-date 
> later than now the user agent appends an entry to the access method 
> check cache for the URI with an expiry date as indicated by the 
> Method-Check-Expires header. This entry contains all the Access-Control 
> / <?access-control?> / Allow / Method-Check-Expires information so 
> requests with a different Referer-Root can also benefit from it.

This all seems fine, but I recommend allowing UAs to have a (small) 
default) expiry time for when the header is missing, like an hour or 
fifteen minutes or something, defined by the UA.


On Mon, 15 Oct 2007, Bjoern Hoehrmann wrote:
> 
> Then please remove the Method-Check header, it is not only unnecessary 
> but also confusing (you give the false impression servers can meaning- 
> fully respond differently depending on it and it complicate the proto- 
> col, for example, it is unclear what to do with Vary: Method-Check).

Method-Check is needed to distinguish invokations intended to just check 
whether a POST (or whatever) is safe, from invokations intended to get the 
actual resource. If a resource would do a lot of work on a GET normally, 
we don't want it to have to do a lot of work when the UA is going to 
ignore all but the headers and the prologue.


> As for OPTIONS on specific resources, I am not sure what configuration 
> might be necessary. With an ordinary CGI script on an Apache server, I 
> can successfully issue a OPTIONS request without any configuration, and 
> the response will include Allow and Access-Control headers just as I 
> specify them in the script. What configurations did you have in mind?

We can't use OPTIONS because Apache returns

   Allow: GET,HEAD,POST,OPTIONS,TRACE

...by default, which would basically mean that out of the box, any 
resource that support cross-site GET would automatically support 
cross-site POST.

Also, OPTIONS doesn't return a body, which is useful to authors who want 
to include the cross-domain rights in XML PIs rather than HTTP headers.


> You didn't say why the processing instruction needs to be processed, 
> could you elaborate on that?

See the draft -- they're core to the access control mechanism.


> I don't understand your point about Referer-Root. What would I have to 
> do with the Referer-Root header's value on the server to ensure that the 
> access check completes successfully as intended? If servers never need 
> to process it, then clients cannot be required to disclose this 
> information.

We need the server to have access to the source's "origin" (scheme-host- 
port) so that if the host has an ACL that is longer than conveniently 
transmittable via headers (or, for that matter, if the list is somewhat 
sensitive, like a list of paying customers) the host doesn't have to send 
the entire list each time, and can instead just check the header for which 
host is being tested, just returning that one.


> If there are cases where servers need to know, why can't they use some 
> other method to get hold of the information, e.g. by configuring the 
> server so that only http://provider.example/user/ can be accessed from 
> http://user.example/? If they can do that, it seems the header should be 
> removed aswell.

Passing the origin information in the URI on a per-origin basis would be 
technically possible but has much higher costs in terms of author 
education (instead of being able to copy-and-paste code from site to site, 
authors would have to actually change each URI being fetched). This 
doesn't scale well in environments like common libraries using this kind 
of feature.

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

Received on Monday, 15 October 2007 19:29:31 UTC