- From: Bil Corry <bil@corry.biz>
- Date: Thu, 09 Apr 2009 00:47:17 -0500
- 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/9/2009 12:21 AM: > On Wed, Apr 8, 2009 at 10:09 PM, Bil Corry <bil@corry.biz> wrote: >> 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. > > Then no one could link to the site. Virtually every site is going to > have some page that both wants to be world-linkable and has different > time characteristics for logged in / not logged in. The Origin header > is useful for many things but not for defeating timing attacks. The site could redirect externally-driven requests to a login page, and once the user logs in again, redirect the user back to the original source. It really depends on the site and what it is trying to accomplish. For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. - Bil
Received on Thursday, 9 April 2009 05:48:07 UTC