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

On Fri, 5 Oct 2007, Henri Sivonen wrote:
> 
> What's the expected threat of a browser performing a non-GET request 
> without being pre-authorized if the response isn't revealed to scripts 
> if the required Access-Control authorization isn't there? Presumably, 
> the danger is that e.g. a POST could change the state of the server-side 
> app. But server-side apps need to be resilient against random POSTs 
> anyway. Is the expectation that the browser would send login credentials 
> automatically with a cross-domain XHR POST? Could those credentials be 
> omitted (until the server demonstrates access-control and Referer-Root 
> awareness) so that non-GET methods could be tried optimistically? Some 
> services, like Validator.nu, don't require login, so as far as the 
> server is concerned, it could handle such an optimistic POST.

Indeed, for POST, servers already have to be resilient to authenticated 
hostile POSTs of arbitrary content, since you can send any authenticated 
data using <form> and text/plain enctypes today. I don't think we need to 
do a pre-check for GET or POST.

For other methods, I don't feel comfortable sending requests, even 
unauthenticated requests, without checking first. Some services 
authenticate based on IP (e.g. intranet servers) and there's no way to do 
an "unauthenticated" request for theirs.


> As for the mechanism for authorizing non-GET methods, why isn't OPTIONS 
> used?

OPTIONS can't be cached. We want this to be cacheable.


> The purpose of the request isn't to retrieve a resource representation, 
> which is what GET is for.

Actually the representation could be useful, since (if it's XML) it can 
contain the <?access-control?> PI.


> The Allow header on OPTIONS responses does not demonstrate that the 
> server knows about cross-domain XHR semantics, but another header name 
> such as Access-Control-Allow on an OPTIONS response could be used to 
> signal that the server responding to OPTIONS has knows about 
> access-control and has had the opportunity to examine Referer-Root.

You need an access-control header or PI in addition to the Allow: header, 
but, yes, I agree, it could have an XHR-specific name for added safety.

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

Received on Friday, 5 October 2007 17:34:12 UTC