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

From: Robert Sayre <[email-masked]>
Date: Sat, 24 Jan 2009 02:08:36 -0500

> 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."

---

From: Adam Barth <[email-masked]>
Date: Sat, 24 Jan 2009 00:00:05 -0800

> As proposed, the Origin header sounds certain to end up on those

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

> 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
> (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

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.

> 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

---

From: Robert Sayre <[email-masked]>
Date: Sat, 24 Jan 2009 07:22:39 -0500

[oops, left off the list]

> header in order to avoid falling into that trap.

The way to avoid falling into that trap is to avoid raising new
privacy concerns. I agree that the problems posed by Origin are not as
severe as the Referer header, in aggregate. But I don't think that is
a very interesting point to dwell on.

> information in the path or query string.

In aggregate, sure.

> Moreover, because we do not

Yes, I understand.

> leaking a host's name to itself.

Sorry, of course. Let's substitute a JS-triggered form post, or even
just a click on something that looks like link but it is an image form
button, and continue productive discussion.

>> Naively:
> POSTing a request to www.facebook.com.

I did call my example out as naive and incomplete...

> You could imagine a more

Seems like it hasn't been needed previously.

>  I suspect these requests are quite rare, but I would welcome hard

Information on the quantity would be nice to have, but I don't think a
new CSRF mitigation technique should introduce a privacy leak,
especially when it looks like there might be a way to avoid it that
you haven't explored.

--

Robert Sayre

-- 

Robert Sayre

---

From: Bil Corry <[email-masked]>
Date: Sat, 24 Jan 2009 08:29:07 -0600

> especially when it looks like there might be a way to avoid it that

The most common use-case for the Origin header is to confirm the request originated from the same host (which is what the "secret token" defense is used for).

One way to avoid privacy issues entirely would be to only send the Origin header when the request is going back to the same host; that still allows a site to avoid CSRF for the most common use-case and the eliminates the privacy issues.  In fact, when done this way, the Origin header can be included for all requests, including GET.  For sites that mis-implement GET, this is probably a more attractive solution anyhow.

- Bil

---

From: Adam Barth <[email-masked]>
Date: Sat, 24 Jan 2009 10:02:11 -0800

> button, and continue productive discussion.

Of course there is no way for the user to determine whether an
intranet site is leaking its host name to the Internet, but a site
that wants to leaks its host name doesn't need the Origin header to do
this.  The vast majority of intranet-to-Internet network requests are
generated from hyperlinks.  Do you have examples of intranet sites
with sensitive host names that POST to untrusted Internet sites?

Without even anecdotal evidence that this occurs, this privacy leak
seems theoretical.  (Of course, I'd prefer hard data to anecdotes.)

> especially when it looks like there might be a way to avoid it that

I welcome suggestions for a solution that address the same use cases
with further privacy protections.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 24 Jan 2009 10:10:51 -0800

> The most common use-case for the Origin header is to confirm the request originated from the same host (which is what the "secret token" defense is used for).

The secret token defense is not limited to a single host name.

> One way to avoid privacy issues entirely would be to only send the Origin header when the request is going back to the same host; that still allows a site to avoid CSRF for the most common use-case…

This is an interesting suggestion and worthy of further thought.
Essentially, this version of the header would convey the same bits in
Rob's proposal but in an easier to understand form.  We should seek
feedback from Web site operators about whether they'd prefer the
Origin header for GET requests or for cross-host requests (with the
constraint that they can't have both for privacy reasons).

I've noted this proposal in the draft.

Thanks for your feedback,
Adam

---

From: Ian Hickson <[email-masked]>
Date: Sat, 24 Jan 2009 20:51:58 +0000 (UTC)

On Sat, 24 Jan 2009, Adam Barth wrote:
> > One way to avoid privacy issues entirely would be to only send the 
> > Origin header when the request is going back to the same host; that 
> > still allows a site to avoid CSRF for the most common use-case and the 
> > eliminates the privacy issues.  In fact, when done this way, the 
> > Origin header can be included for all requests, including GET.  For 
> > sites that mis-implement GET, this is probably a more attractive 
> > solution anyhow.
> 
> feedback from Web site operators about whether they'd prefer the Origin 
> header for GET requests or for cross-host requests (with the constraint 
> that they can't have both for privacy reasons).

This solution would fail to satisfy the original use case of Origin, 
namely to let the server in an XHR2 scenario know who the origin was so it 
could make educated decisions about letting information out.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Robert Sayre <[email-masked]>
Date: Sat, 24 Jan 2009 16:38:54 -0500

> seems theoretical.  (Of course, I'd prefer hard data to anecdotes.)

It no doubt occurs, since the web makes it easy to do. Do you
disagree? I agree the quantity is hard to guess at, and the nature of
the problem makes it hard to get data for, if you think about it.
Again, I don't think the quantity argument is a good one, since the
problem is that people can install a new browser and leak data in new
ways, by default. In my project, it's unusual to dismiss security or
privacy bugs by saying "well, it only happened to a few people".

Asking people to provide data is often a good thing, especially when
they're proposing features, but in this case it seems like you're
using it to squash a pretty valid concern when the burden of proof is
on you. Where would such a rhetorical tactic fly?

It's your piece of http space junk. :)

> with further privacy protections.

Didn't I just give one, or do you want me to design a full URL
comparison for you? I guess I can throw something together if you
insist. I'm sure it could cover the facebook example you gave. It
wouldn't cover the case where you actually want to allow some
syntactically unrelated host to submit POST requests via a whitelist.
That seems like a reasonable trade off to me.

> could make educated decisions about letting information out.

This could change things, since this seems to /require/ leaking the
host name. But "educated decisions" is a pretty vague term.

That said, cross site XHR2 as proposed in the W3C is pretty bloated
and complex. Having to mint a different header for that use seems like
a drop in the bucket.

-- 

Robert Sayre

---

From: Bil Corry <[email-masked]>
Date: Sat, 24 Jan 2009 17:27:52 -0600

> could make educated decisions about letting information out.

Doesn't XHR2 send the Origin header for GET?  That's prohibited by Adam's Origin draft, so either way, the Origin header discussed here will not exactly match the Origin header as provided by XHR2 via Access Control.

- Bil

---

From: Adam Barth <[email-masked]>
Date: Sat, 24 Jan 2009 15:31:05 -0800

On Sat, Jan 24, 2009 at 3:27 PM, Bil Corry <[email-masked]> wrote:
> Doesn't XHR2 send the Origin header for GET?  That's prohibited by Adam's Origin draft,

That is not prohibited by the draft.  The draft has only positive
requirements on sending the Origin header.

> so either way, the Origin header discussed here will not exactly match the Origin header as provided by XHR2 via Access Control.

One of our goals is to have the Origin header used by XHR2 via Access
Control comply with the requirements of this draft.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 24 Jan 2009 15:51:21 -0800

On Sat, Jan 24, 2009 at 1:38 PM, Robert Sayre <[email-masked]> wrote:
> disagree?

Even if it does occur, the document.referrer property is a much larger
privacy leak than the Origin header because:

1) document.referrer is present for GET requests (e.g., simple hyperlinks)
2) document.referrer is not suppressed by proxies

> I agree the quantity is hard to guess at, and the nature of

I'm attempting to gather data on this point.  I'll report back if/when
I have hard data I can share.

> privacy bugs by saying "well, it only happened to a few people".

The quantity is important.  If intranet sites with sensitive host
names POST to untrusted Internet sites as often as intranet sites with
sensitive host names, paths, or query strings have hyperlinks to
untrusted Internet sites, then we should worry a lot about this issue.
 If this occurs 10,000x less often, then I don't believe this is a
large concern.

> on you. Where would such a rhetorical tactic fly?

I agree that the person proposing to change the status quo has a
higher burden of proof, but we have yet to see a single anecdotal
example of the problem you imagine.

> insist.

You're welcome to contribute another solution.  I'm glad that Bill
contributed his proposal.  I welcome more proposals.

Adam

---

From: Bil Corry <[email-masked]>
Date: Sat, 24 Jan 2009 20:52:24 -0600

> requirements on sending the Origin header.

Ah, then it's just a matter of semantics.  If the CSRF Origin was written to have "only positive requirements" to send the Origin header when the Origin is itself, then it wouldn't preclude the XHR2 Origin from sending it on cross-site requests.  I believe that would then address Ian's concern, correct?

- Bil

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 26 Jan 2009 11:00:59 +0100

> being appealing, since it doesn't require any analysis of internal

What if the UA discard the Origin value (i.e. use "null" or some other
value) when crossing "zone" boundaries?
When an Intranet web page issues a request to an Internet resource,
then the UA SHOULD send "Origin: null" instead of "Origin:
http://<intranet-server>".

Could it work? (I suppose this could be done based on which range the
IP-address of the target resource belongs to, after DNS resolution;
but maybe DNS resolution doesn't always happen depending on the proxy
configuration –I don't know how this works)

> target URI.

It would rule out communication from/to myproduct-tm.com to/from
mycompany.com, and it would make Origin much less appealing...
I believe there are legitimate needs for cross-site requests that are
not CSRF attacks (product-to-company; federated SSO; etc.)

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Mon, 26 Jan 2009 13:25:13 -0800

> not CSRF attacks (product-to-company; federated SSO; etc.)

Yes, I fully agree that it would rule out stuff like that. If the goal
of the header is to selectively allow cross-site requests from
arbitrary domains, my suggestion won't work. If the goal is only to
block CSRF, then the Origin header sends much more information than
necessary. The fact that you think it will be useful for federated SSO
should be a warning sign.

So, does the header send more information than necessary? Beats me. If
it does, then the author should come up with a little syntax to
characterize the delta between two URIs, at least to the level of host
component similarity. I do not think it is one of technology's great
unsolved problems. It is also not my job to produce such a syntax,
despite the author's implications otherwise. It might be the case that
it's more information than necessary, but it's not worth fixing the
header to make it send less information. It's hard to debate such a
point without knowing (wait for it) whether the header sends more
information than necessary.

Given the number of times unforeseen reuse has caused clients,
proxies, and servers have to block access to headers in various ways,
you'd think the most minimal approach would be best.

You can Solve Any Problem... ...if you're willing to make the problem
small enough.

-- 

Robert Sayre

---

From: Adam Barth <[email-masked]>
Date: Mon, 26 Jan 2009 16:11:08 -0800

> value) when crossing "zone" boundaries?

That's an interesting idea.  I'm not sure we have the notion of a
"zone" available to us at this level of abstraction.  Internet
Explorer certainly has that concept, but I'm not sure other browsers
do.

> http://<intranet-server>".

We could recommend this in the non-normative privacy considerations
section.  It's certainly permitted by the current draft.

> configuration –I don't know how this works)

I don't think we want to go about specifying this in detail.  We're
unlikely to get it right considering that IE let's the user configure
what sites are in which zones.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 26 Jan 2009 16:25:05 -0800

On Mon, Jan 26, 2009 at 1:25 PM, Robert Sayre <[email-masked]> wrote:
> So, does the header send more information than necessary? Beats me.

I don't think "minimum necessary" is the right criterion for
evaluating the design.  Instead, we should consider the costs/benefit
trade-offs.  There are clearly benefits to sending the Origin header
to other hosts (supports web applications that span more than one host
name).  We disagree about the costs in terms of intranet-to-Intenet
leakage of host names from POST requests.

> you'd think the most minimal approach would be best.

Some of these unforeseen reuses might turn out to be valuable.

I believe we've responded to the lion's share of privacy concerns by
not sending the Origin header for GET.  So far, we haven't heard a
single anecdote about a intranet site that would be sad that we sent
the Origin header for POST.  I'm attempting to gather hard data on
this point.

Adam

---

From: Emilio Casbas <[email-masked]>
Date: Tue, 27 Jan 2009 01:36:25 +0100

> Explorer certainly has that concept, but I'm not sure other browsers

It seems not.
http://code.google.com/p/browsersec/wiki/Part3#Microsoft_Internet_Explorer_zone_model

> section.  It's certainly permitted by the current draft.

If the Origin header is sent only for POST requests, the probability for
intranet leakage information
is almost null in examples like previously cited.

Regards
Emilio