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

> Adam Barth wrote:
>>> The problematic case is when the Referer header is suppressed by the
>>> network (e.g., proxies).  In this case, the Referer header is
>>> suppressed regardless of its value.  Choosing a different value will
>>> not help Web sites defend themselves against CSRF.
>> Ok - hold up... a 'strict' proxy which is stripping all but trusted
>> headers is going to pass the Origin header, why?
> According to my experiments, this is not how proxies function.
> Instead, proxies strip headers on a blacklist of headers.  A user
> behind a hypothetical "strict" proxy you describe would be unable to
> use many existing Web sites because those sites require custom
> headers, such as X-JSON, to function properly.
>> If you can't fix the bug in the proxies, adding another header for
>> them to ignore is not a solution.
> In fact, the vast majority of proxies leave the Origin header
> unmolested and so do not do not require modification.

As proposed, the Origin header sounds certain to end up on those
proxies' blacklists.

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. Secondly, it's easy to
generate POST requests with things that look like they should be GETs
(thanks to XHR). 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.

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

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

- Rob


Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Received on Saturday, 24 January 2009 07:09:11 UTC