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

Ian Hickson wrote:
> 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.

I'm not comfortable doing POST without checking if it's safe first 
either. I do realize that this is something that can already be done 
today, but I suspect that is already a problem, just one that hasn't 
gotten exploited yet. So I'd rather not add to that if I can avoid it.

For methods like DELETE it could obviously be harmful to send to random 
servers that support that method. Like Ian points out, there might very 
well be servers living inside firewalls that support that method and 
don't do any other security authentication other than relying on the 
firewall.

Also note that the server can make the GET request be cached in the 
browser which should make the overhead of a GET fairly low.

/ Jonas

Received on Saturday, 6 October 2007 00:57:27 UTC