Adam Barth wrote on 4/7/2009 11:54 AM:
> On Mon, Apr 6, 2009 at 2:09 PM, Bil Corry <b...@corry.biz> wrote:
>> Can we please include the Origin header for all same-origin requests,
>> including GET and HEAD? Or is there a compelling reason why not do to so?
>>
>> Also, would there be value in having Origin sent for *all* requests, and if
>> populating Origin is prohibited for that request (e.g. cross-origin GET), it
>> sends "null" as the value?
>
>
> In order to make the Origin header a workable CSRF defense for GET,
> we'd have to send "null" on cross-origin GET requests (otherwise the
> attacker can suppress the header by making a GET request from another
> origin). However, this is inconsistent with CORS.
How set in stone is Origin within CORS? When brought up before, the consensus
was Origin within CORS couldn't be changed due to Microsoft shipping IE8.[1]
But now Doug Schepers is asking for a review of Origin within CORS[2] which
makes me think it may be open to modification if warranted.
The ideal scenario would be to merge all the various proposed Origin
specifications into one that is well thought out and handles the bulk of the
use cases. But this is predicated on being able to modify Origin as it appears
in CORS; otherwise we're left with either at least two headers, or changing the
behavior of all to match CORS, or making the header contextual, so that it is
sent one way when via CORS, and another when it's not.
At this point, I'm aware of four Origin descriptions, are there any others?
CORS: http://www.w3.org/TR/cors/#origin-header
HTML5:
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step
Barth: http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
Moz: https://wiki.mozilla.org/Security/Origin
- Bil
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0090.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0031.html
