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

On Thu, Jan 22, 2009 at 4:20 PM, Mark Nottingham <> wrote:
> Personally, I tend to agree; the number of problems caused by scripting are
> voluminous, and I think we'd do well to question its boundaries.

An attacker can mount a CSRF attack without scripting simply by using
an HTML <form> element.

> However, AIUI Origin isn't about exposing credentials, directly. The Referer
> header would be just as adequate for this purpose (assuring that the
> originating content is from an allowed host), except that the authors feel
> that Referer is stripped by proxies and user-agents in an attempt to improve
> privacy / limit exposure of sensitive data in URIs.

Indeed.  The Referer header is stripped by proxies frequently enough
to make it unusable as a CSRF defense over HTTP.

> I don't think this argument is valid. The number of proxies that do this is
> very small.

In fact, this occurs for about 3% of users, which is a significant number.

> Those that exist will come under pressure to change their
> behaviour when their users notice that Web applications that rely upon this
> feature break behind those proxies.

Unfortunately, these proxies prevent Web sites from relying on the
Referer header, and so the operators of these proxies never come under
pressure to stop suppressing the header.

> In other words, just as the authors are satisfied having a staged deployment
> where some browsers on the Web support cross-site requests using their
> mechanism, while some still do not, I see no reason why it isn't just as
> acceptable to accept that some proxies will support it, and some will not;
> over time, more will.

The difference is that there is a deployment plan self-interested
agents to bring about the usefulness of the Origin header for CSRF
defense, but there is no such plan for the Referer header.

Origin header deployment plan:

1) Each user agent implements the Origin header and advertise that
they support more secure than those that do not implement the header.

2) Sites add rules to their Web application firewall rules to protect
those of their users that use a supporting browser.

3) Users choose supporting user agents because they are more secure.

4) Supporting user agents come to dominate the market.

> I think they're relying on existing browsers not allowing cross-site
> requests at all programmatically, and not having the ability to manipulate
> headers using other means (e.g.,   script src, etc.).

I am not aware of a popular browser that allows sites to spoof the
Origin header in cross-site requests.

> unless the server decides to
> also allow requests that omit the Origin header altogether.

In fact, the ID requires participating sites to do this.

> If they do that,
> however, it seems like a non-programmatic, non-Origin-creating browser would
> leave a hole...

Can you explain this hole?

Thanks for your feedback,

Received on Friday, 23 January 2009 01:45:58 UTC