Re: FW: CORS and HTTP headers spoofing

On 6/3/11 6:02 AM, Margarita Podskrobko wrote:
> In this particular case, the user might be not aware that there is any
> this kind of addon running in browser and changing the value of Origin
> header.

If the user doesn't know what addons are running in the browser, then 
the user is screwed.  Addons can break the security model in pretty 
arbitrary ways, on purpose.

> And then it is becoming even easier for CSRF, as XHR can be sent
> automatically and user even doesn't need to click to any malicious link.

An addon can do anything the browser itself can do.  So if the user can 
visit a site, an addon can scrape the site.  An addon is just part of 
the browser, for security purposes.  Not trusting it is equivalent to 
not trusting the browser itself.  Possibly rational, but useless in 
practice unless you're just planning not to use that browser at all.

>  > CORS was mostly written with the intent of protecting the users data
>  > which is stored in various web servers. Obviously the user attacking
>  > the webserver to steal his or her own data isn't much of a concern.
>  > This is why I'm asking the above question.
>
> I am trying to figure out, how the Origin header of request should be
> used on the side of server. Adam Barth wrote the following in
> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1255.html:
>
> "My understanding is that the CORS use of the Origin header is mostly
> to protect the confientiality of resources on the server.  For
> example, if (1) the server wishes to reveal a particular piece of
> information to some origins by not to others."

This implies the server trusting that the browser won't purposefully try 
to screw that up.  There is no way to protect against the browser (or 
heck, the _user_) being malicious.  Consider that the user could just 
get the data from the server and then e-mail it to some other website.

The idea here is that the _user_'s data is on the server and the user 
wishes it to be secure.  The server allows some other sites but not 
others to access the data because the sites it allows are trusted and 
need to work with the data.  If the user wishes to circumvent this 
setup, that's fine: it's the user's data to start with.

Servers that want to protect their _own_ data just need to not put it on 
the web at all, and they're done!

-Boris

Received on Friday, 3 June 2011 13:02:54 UTC