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

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


Received on Friday, 23 January 2009 02:22:29 UTC