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: Thu, 22 Jan 2009 18:21:48 -0800
Message-ID: <7789133a0901221821s6239e698k2cf2892bf332b65c@mail.gmail.com>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, Larry Masinter <LMM@acm.org>, ietf-http-wg@w3.org, Lisa Dusseault <ldusseault@commerce.net>

On Thu, Jan 22, 2009 at 5:58 PM, William A. Rowe, Jr.
<wrowe@rowe-clan.net> wrote:
> 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.

> They only
> have RFC2616 to strip hop-by-hop headers, so I would study this
> problem set from the scope of non-compliant proxies and explain
> to that group (through a best practices RFC or direct bug report)
> why this is harmful.

I suspect the operators of these proxies will ignore such efforts
because they have business reasons for stripping the Referer header.
For example, it is common in enterprise configurations to strip the
Referer header to prevent intranet URLs from leaking to Internet Web
sites.

Adam
Received on Friday, 23 January 2009 02:22:29 GMT

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