Re: Origin (was: Re: XHR LC Draft Feedback)

On Sat, May 24, 2008 at 1:57 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 24 May 2008 10:32:03 +0200, Anne van Kesteren <annevk@opera.com>
> wrote:
> It has been suggested that having an "Origin" header instead of
> "Access-Control-Origin" would be useful in other contexts as well. That
> browsers could always include this as it does not have the privacy issue the
> "Referer" header has (does not include the path) and could therefore be used
> for Access Control but also to prevent CSRF.
>
> I'm not really sure whether that is a good idea, but you (Adam) and Collin
> can hopefully weigh in on that. :-)

You can find a lot of articles written by people who are sad they
can't use the HTTP Referer header to prevent CSRF.  The two main
issues with using the Referer header are (1) an attacker can easily
suppress the header (for example by issuing the cross-site request
from an FTP URL) and (2) legitimate requests often lack the header.

Collin and I tested issue (2) experimentally by running a web
advertisement that issued a number of network requests to our servers,
and we observed that, indeed, the Referer header is often missing for
HTTP requests (although it is almost always present for HTTPS
requests).  Here are two charts summarizing our observations:

http://crypto.stanford.edu/~abarth/research/webapi/referer/

The data seems to indicate that the Referer header is most often
suppressed in the network layer due to privacy concerns.  We think the
header is suppressed in the network layer because the
document.referrer value is very often not suppressed (browser-layer
suppression preferences block both the header and document.referrer),
and the header is often not suppressed over HTTPS.  The evidence that
the header is suppressed for privacy reasons is that the header is
suppressed much less often for same-site requests than for cross-site
requests.

We suggest that user agents attach an Origin header to POST requests.
This balances the security benefits of easy CSRF protection with the
privacy costs.  If user agents attached this header, sites could
protect themselves from CSRF by (2) undertaking state-modify actions
only in response to POST requests and (2) implementing the below web
application firewall rule (e.g., ModSecurity rule):

SecRule REQUEST_HEADERS:Host !^www\.example\.com(:\d+)?$ deny,status:403
SecRule REQUEST_METHOD ^POST$ chain,deny,status:403
SecRule REQUEST_HEADERS:Origin !^(https?://www\.example\.com(:\d+)?)?$

People often suggest that we should attach the Origin header to GET
requests as well as POST requests.  This increases the security
benefits of the proposal, but it also increases the privacy cost
because the header would then be sent for every hyperlink click.  Many
organizations suppress the Referer header at their network boundary to
prevent external sites from learning the structure of their internal
network.  While the Origin header does not include the path (and thus
reveals much less information), the names of internal hosts might
still be sensitive.  We think restricting the header to POST requests
will discourage these organizations from suppressing the header
because it is much less common for an internal site to POST to an
external site (compared with how common it is for an internal site to
hyperlink to an external site).

Of course, XHR2 could use the Access-Control-Origin header and this
proposal could use the Origin header, but the two are conceptually
very similar and it might be worthwhile to use the same header name.

Adam

Received on Saturday, 24 May 2008 18:48:43 UTC