Adam Barth wrote on 4/8/2009 11:23 PM:
> On Wed, Apr 8, 2009 at 1:32 PM, Bil Corry <b...@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 ...
http://www.sensepost.com/research/squeeza/dc-15-meer_and_slaviero-WP.pdf
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
