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

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

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 24 Jan 2009 00:00:05 -0800
Message-ID: <7789133a0901240000r3ac5cb3fm3f9f87041d5ed00d@mail.gmail.com>
To: Robert Sayre <sayrer@gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

On Fri, Jan 23, 2009 at 11:08 PM, Robert Sayre <sayrer@gmail.com> wrote:
> As proposed, the Origin header sounds certain to end up on those
> proxies' blacklists.

We've tried to respond to the privacy concerns raised by the Referer
header in order to avoid falling into that trap.

> It can be difficult to police host names across an organization. There
> is no reason to assume a string like "iphonekiller" (to use your
> example) won't end up in the Origin header.

Certainly this is conceivable, but much less likely that sensitive
information in the path or query string.  Moreover, because we do not
send the Origin header for GET requests, these leaks require (in
addition to a sensitive host name) a POST from an internal server to
an external server.

> Secondly, it's easy to
> generate POST requests with things that look like they should be GETs
> (thanks to XHR).

In all currently deployed browsers, XHR can only generate POST
requests back to the same origin.  Surely we're not worried about
leaking a host's name to itself.

> I can definitely see blocking Origin at the firewall
> being appealing, since it doesn't require any analysis of internal
> host names or XHR usage.

Even if we find ourselves in a situation where 3% of users have the
Origin header removed by network proxies (a situation I think unlikely
for the reasons outlined above), the Origin header will still be an
effective CSRF defense for the remaining 97% of users because the
users behind the stripping proxies will appear to be non-supporting
user agents.

Unlike the Referer header, which requires 100% deployment to be an
effective CSRF defense for anyone, the Origin header is an effective
CSRF defense for whatever fraction of users have supporting user
agents.

> Thus I think it's a mistake to reveal the originating host name.  This
> proposal would probably be much more likely to succeed if someone
> devised a way to describe the "URI proximity" of the origin URI to the
> target URI. Naively:
>
> schemes differ: 0
> scheme same, hosts differ: 1
> ...

This scheme rules out the common use case of berkeley.facebook.com
POSTing a request to www.facebook.com.  You could imagine a more
complex "URI proximity" description that supports this use case, but I
haven't seen a good one.

> I realize this approach is much more difficult to specify effectively.

We could, perhaps, ask someone who operates a enterprise proxy that
strips the Referer header to measure how often a POST request to an
external URL has an internal host as a Referer.  This would allow us
to evaluate how much information would be leaked by the Origin header.
 I suspect these requests are quite rare, but I would welcome hard
data on this point.

Adam
Received on Saturday, 24 January 2009 08:00:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:00 GMT