W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Do we need to rename the Origin header?

From: Bil Corry <bil@corry.biz>
Date: Thu, 09 Apr 2009 00:09:22 -0500
Message-ID: <49DD8302.3020605@corry.biz>
To: Adam Barth <w3c@adambarth.com>
CC: Thomas Roessler <tlr@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, Maciej Stachowiak <mjs@apple.com>, Sam Weinig <weinig@apple.com>, Sid Stamm <sstamm@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>
Adam Barth wrote on 4/8/2009 11:23 PM: 
> On Wed, Apr 8, 2009 at 1:32 PM, Bil Corry <bil@corry.biz> wrote:
>> BTW, one reason to do this is to help deter timing attacks.  Any request that arrives for the login page or a protected page that isn't same-origin can be redirected to a common landing page.
> This doesn't make much sense.  People mount timing attacks against the
> login from from their own machine (where they can send whatever
> headers they like).

Imagine a scenario where you want to know if your visitor is logged in on your competitor's site.  So you add a hidden iframe on your site that points to a protected resource on your competitor's site.  By measuring how long it takes to load, you can determine if your visitor is logged in on your competitor's site (the assumption being that if they're not logged in, the site will respond quickly and tell them to log in).

That's the type of timing attack I was referring to.  This paper does a much better job explaining it; see section 6 on page 10:

	It's all about the Timing ...

Using the above scenario, if Origin was populated and sent for all same-origin requests (including GET), the website could simply redirect any request for any protected resource that isn't same-origin.  That would prevent an attacker from timing how long a page loads because it'd load the same for all requests, regardless if the user is logged in or not.

That's one reason why it's important that Origin (or something similar) be sent for all requests.  I get that it's too late to do anything about CORS-Origin (and now HTML5-Origin).  However, the utility of a fully-featured Origin is too strong to ignore (anti-CSRF, anti-timing attack, anti-clickjacking, etc).  Should a fully-featured Origin substitute ever make it into the mainstream UAs, no one will use Origin any more as the new header would do everything Origin now does, plus much more.

- Bil
Received on Thursday, 9 April 2009 05:10:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC