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

On Fri, Jan 30, 2009 at 12:23 AM, Mark Nottingham <mnot@mnot.net> wrote:
> On 25/01/2009, at 10:16 AM, Adam Barth wrote:
>> 1) The attacker can force a user agent to suppress the Referer header,
>> mimicking a user behind a Referer-stripping proxy.
>
> Can you walk us through this attack, please? Or give a reference...

As Thomas says, there are lots of ways to do this, mostly by design.
Here is a list of the top of my head:

1) The attacker hosts his HTML page over HTTPS and mounts a CSRF
attack against an HTTP URL.
2) The attacker hosts his HTML page over FTP.  Browsers don't send FTP
URLs in the Referer header.
3) The attacker hosts his HTML page over GOPHER.  Browsers don't send
GOPHER URLs in the Referer header
4) The attacker hosts his HTML in a DATA URL.  Browser don't send DATA
URLs in the Referer header.
5) The attacker hosts his HTML in a frame whose URL is the empty string.

There are many more ways, but none of these are bugs.

>> 2) The attacker cannot force a supporting user agent to suppress the
>> Origin header and therefore cannot mimic a non-supporting user agent.
>
> This supposes perfect implementation...

Bugs happen, but they get patched.  If users aren't applying patches,
then they will very quickly have a user agent that is vulnerable to
much more severe attacks (e.g., universal cross-site scripting or
arbitrary code execution).

That said, it's actually pretty easy to enforce this property.  You
just add a branch in the code near where the request hits the wire
that says "if this is a non-safe request and I don't have an Origin
header yet, add "Origin: null".

Adam

Received on Friday, 30 January 2009 17:56:51 UTC