Re: Do we need to rename the Origin header?

On Mon, Jan 12, 2009 at 5:31 PM, Jonas Sicking<jonas@sicking.cc> wrote:
> There has been a lot of discussions lately in various forums about
> using an "Origin" header as a cross site request forgery (CSRF)
> protection mechanism. The idea has been to let the Origin header
> indicate who is causing the request, and can be used for sites to more
> easily see if the request is something that the site initiated itself,
> or if it comes from an untrusted third party and should be ignored.
>
> However, this is not how the 'Origin' header in Access-Control works.
> Here the "Origin" header refers to the origin of the site which is
> trying to read data. I.e. where any data returned is going to be sent
> (or in the case of the preflight request, which site you are
> authorizing to make a request).
>
> The two are different in the case of redirects. For example:
>
> Site A uses Access-Control to fetch a resource from site B using a
> normal GET request
> Site B redirects the request to site C.
>
> When the browser follows the redirect and makes the request to site C,
> Access-Control demands that the Origin is "A". However that doesn't
> make sense from a CSRF protection point of view since site B is the
> one deciding what request to perform to site C.
>
> Current HTML5 drafts say that on a redirect the "Origin" should be set
> to "null", which makes sense from a CSRF protection point of view, but
> makes it incompatible with "Origin" as defined by Access-Control.
>
> There are 3 possible solutions that I can see to this:
> 1. Change the name of the Origin header in Access-Control
> 2. Change the name of the Origin header used for CSRF protection
> 3. Change the behavior of one (or both) of the specs such that they
> match in behavior.

I've taken option (2) in the CSRF spec.  I'm hopeful that we can
harmonize the behavior of the two use cases.  If we can do that, we
can harmonize the names as well.

Adam

Received on Sunday, 28 June 2009 23:02:47 UTC