W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

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

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 22 Jun 2008 00:49:57 -0700
Message-ID: <7789133a0806220049k58e8abf9v9f9bf3d8089365d2@mail.gmail.com>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: "Collin Jackson" <w3c@collinjackson.com>, public-webapps@w3.org

On Sat, Jun 21, 2008 at 6:51 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> The stated goal was to balance easy protection against session riding
> attacks without compromising privacy too much. Allowing session riding
> via some sites but not others is something that cannot be done securely
> today without major effort as whatever information is used to tell good
> requests apart from bad requests may either be absent or faked.

The Origin header is hard to fake because XHR2 doesn't allow it to be
set across domains and XHR1 is for same-origin requests only.  A
supporting browser will not omit the Origin header for POST request.
In situations were no origin is appropriate (say from for a data URL),
a supporting browser will send the value "null".

Consider a site like Facebook or Slashdot that uses a number of
subdomains (e.g., stanford.facebook.com or it.slashdot.org).  It is
entirely reasonable for the site to POST requests between these
origins.  Sending "Pragma: cross-site" doesn't let the site use this
feature to defend against CSRF, but sending "Origin:
http://it.slashdot.org" does.

> That'll remain so until any browser that does not set the header can be
> blocked.

There are three cases:

1) Origin header missing:  This is a non-supporting browser.  Fall
back to existing CSRF defenses.
2) Origin header has a trusted value:  Accept the request.
3) Origin header has an untrusted value:  Reject the request.

This is the behavior of the ModSecurity rule earlier in this thread.
Users of supporting browsers get enhanced CSRF protection.  Attackers
cannot forge the Origin header in cross-origin requests in today's
browsers.  Site can use the header immediately, without having to wait
for non-supporting browsers to become unused.

> I would hope that at that point, other means of cross site and document
> communication are more attractive to developers than what is currently
> not affected by same-origin restrictions, and hope that new ways of by-
> passing the same-origin restrictions will not rely on the Origin header
> alone, so I don't think there is any real advantage. Perhaps I'm missing
> something?

Not all web sites are contained within a single origin.  This feature
is not intended to enable cross-origin communication via POST
requests.  The feature is intended to make it easy for site
developers, or web application firewall vendors, to defend against
CSRF attacks.

Adam
Received on Sunday, 22 June 2008 07:50:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT