- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 21 Dec 2009 17:44:17 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Kenton Varda <kenton@google.com>, Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>
On Mon, Dec 21, 2009 at 5:35 PM, Adam Barth <w3c@adambarth.com> wrote: > On Mon, Dec 21, 2009 at 5:17 PM, Kenton Varda <kenton@google.com> wrote: >> The problem we're getting at is that CORS is being presented as a security >> mechanism, when in fact it does not provide security. Yes, CORS is >> absolutely easier to use than UM in some cases -- I don't think anyone is >> going to dispute that. The problem is that the security it provides in >> those cases simply doesn't exist unless you can ensure that no resource on >> *any* of your allowed origins can be tricked into fetching your "protected" >> resource for a third party. In practice this will be nearly impossible to >> ensure except in the most simple cases. > > Why isn't this a big problem today for normal XMLHttpRequest? Normal > XMLHttpRequest is just like a CORS deployment in which every server > has a policy of allowing its own origin. Because CSRF-like attacks happen when you've got a scenario with more than two parties. A same-origin only scenario has only two parties. The purpose of CORS is to address cross-origin scenarios where there are more than two parties. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Tuesday, 22 December 2009 01:44:50 UTC