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

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

Received on Thursday, 25 June 2009 02:07:03 UTC