W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: The HTTP Origin Header (draft-abarth-origin)

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 25 Jun 2009 15:46:10 +1000
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <LMM@acm.org>, ietf-http-wg@w3.org, Lisa Dusseault <ldusseault@commerce.net>
Message-Id: <EBFD307C-AC0B-481B-BD74-76170E7CD133@mnot.net>
To: Adam Barth <w3c@adambarth.com>
Do you have a spec for sec-from? And, does that imply that Origin  
isn't necessary?

On 25/06/2009, at 12:06 PM, Adam Barth wrote:

> On Wed, Jun 24, 2009 at 6:29 PM, Mark Nottingham<mnot@mnot.net> wrote:
>> Right -- and that's why we're modifying referer to allow about:  
>> blank.
>> The question I have is whether this makes Referer adequate for the  
>> use cases
>> that the various W3C WGs have for Origin (assuming that they'll place
>> additional requirements on it).
> I'll respond to all the feedback as time permits (hopefully in the
> next day or two).  To answer your specific question, the Referer
> header doesn't cover the following use case:
> 1) The honest server changes state in response to a GET request.
> 2) The honest server let's the attacker inject hyperlinks to untrusted
> sites (e.g., as a comment on a news article).
> In this case, the honest server cannot use the Referer header as a
> CSRF defense.  When the user clicks on the hyperlink, the user agent
> will send a GET request to attacker.com with the honest server's name
> in the Referer header.  The attacker can then redirect the request
> back to the honest server.  The Referer header will still implicate
> the honest server, and the honest server will change state
> erroneously.
> The Sec-From header resolves this issue by including the origins of
> each URL in the redirect chain.
> Adam

Mark Nottingham     http://www.mnot.net/
Received on Thursday, 25 June 2009 05:46:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC