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

Jonas Sicking wrote:
> Alternatively we could just give up on caching this and either say that 
> POST is going to be slow, or say that POST doesn't need an access check. 
> I'm still reluctant to do the latter though.

So I talked with Jesse, one of our security guys, and we came up with 
one risk pretty quickly.

First of all, what we want to protect against are POST submissions to 
foreign servers that cause harmful side effects. Servers that use SOAP 
would be one example of servers that are sensitive to this, they use XML 
sent using POST and can perform all manners of operations based on the 
data in the XML.

This is especially an issue if the submission contains login information 
such as username/password or cookies. However it is also an issue 
without that as the user might be sitting on the same network as servers 
that are only protected using network-wide firewalls.

It has been suggested that sending XML data using POST is already 
possible using normal HTML forms and text/plain encoding. Servers thus 
already need to protect against it and so it should be safe to let 
XMLHttpRequest do the same.

One important difference though is that plain/text encoded HTML forms 
are always sent using the data type "plain/text". It is therefor 
possible that a SOAP server won't treat it as XML data and not do 
anything harmful with it.

If we allow XMLHttpRequest to POST cross origin without first performing 
access checks we will be allowing XML data to be sent as application/xml 
which would be interpreted by a SOAP server.

I therefor think that we do need to authorize before cross-domain POSTs, 
and I think we should figure out a way to cache the result of that 
authorization. Possibly using an extra header as suggested by Anne.

/ Jonas

Received on Thursday, 11 October 2007 00:37:04 UTC