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

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 25 Jun 2009 01:08:54 +0200

tor 2009-01-22 klockan 17:35 -0800 skrev Adam Barth:
> I experimentally measured how often the Origin header is dropped in
> the real world, an it is not dropped greater than 99.9% of the time.

So the actual motivation for Origin is because Referer is dropped in
some networks, while the still unknown Origin header is not dropped in
the same networks?

And why is this? Imho simply because the network admins who worry about
Referer do not yet know about Origin. Once they learn about Origin they
will start filtering that header in the same manner as they do with
Referer, putting you back on square one, implementing Origin2?

Regards
Henrik

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Jun 2009 16:28:08 -0700

> some networks, while the still unknown Origin header is not dropped in

We've covered this issue before.  You can find the answer by reading
the whole thread.  In summary, servers cannot distinguish between the
user agent not sending a Referer header and the header being stripped
in the network, making it impossible to use the Referer header as a
CSRF defense without locking out a non-trivial number of users.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Jun 2009 11:29:54 +1000

Right -- and that's why we're modifying referer to allow about: blank.

The question I have is whether this makes Referer adequate for the use  
cases that the various W3C WGs have for Origin (assuming that they'll  
place additional requirements on it).

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 25 Jun 2009 03:57:25 +0200

> Right -- and that's why we're modifying referer to allow about: blank.

Yes, I got that after sending my response. Didn't notice my mail agent
had jumped back 6 months (thought I was just one month back in the
list...)

> place additional requirements on it).

I guess it also needs to extend the browser profile to allow abbreviated
Refererer header values in several cases where the browser sends none
today, such as when switching from https to http.

Regards
Henrik

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Jun 2009 19:06:03 -0700

On Wed, Jun 24, 2009 at 6:29 PM, Mark Nottingham<[email-masked]> wrote:
> The question I have is whether this makes Referer adequate for the use cases
> that the various W3C WGs have for Origin (assuming that they'll place
> additional requirements on it).

I'll respond to all the feedback as time permits (hopefully in the
next day or two).  To answer your specific question, the Referer
header doesn't cover the following use case:

1) The honest server changes state in response to a GET request.
2) The honest server let's the attacker inject hyperlinks to untrusted
sites (e.g., as a comment on a news article).

In this case, the honest server cannot use the Referer header as a
CSRF defense.  When the user clicks on the hyperlink, the user agent
will send a GET request to attacker.com with the honest server's name
in the Referer header.  The attacker can then redirect the request
back to the honest server.  The Referer header will still implicate
the honest server, and the honest server will change state
erroneously.

The Sec-From header resolves this issue by including the origins of
each URL in the redirect chain.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Jun 2009 15:46:10 +1000

Do you have a spec for sec-from? And, does that imply that Origin  
isn't necessary?

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Jun 2009 22:55:10 -0700

On Wed, Jun 24, 2009 at 10:46 PM, Mark Nottingham<[email-masked]> wrote:
> Do you have a spec for sec-from?

http://tools.ietf.org/html/draft-abarth-origin-01

This draft addresses the technical feedback I have receive on the -00
version of the draft.  As I said in the previous email, I'm going to
try to reply to all the outstanding emails in the next couple of days.

> And, does that imply that Origin isn't necessary?

I renamed the header in the draft in order to avoid conflicting with
CORS.  I'm hopeful that we can convince CORS to change its use of
Origin to match (because CORS has similar redirect issues).  If/when
that happens, we can unify the names again.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Jun 2009 15:56:21 +1000

Ah, thanks, will take a look.

Cheers,