- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 21 Apr 2010 16:57:43 -0700
- To: Dirk Pranke <dpranke@chromium.org>
- Cc: Ojan Vafai <ojan@chromium.org>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Apr 21, 2010 at 2:43 PM, Dirk Pranke <dpranke@chromium.org> wrote: > Similarly, if it is really your intent to stop CORS from getting > implemented, you're going to have to sell that harder, because (to > switch metaphors), if that ship hasn't already sailed, it is at least > boarding. I'd like to check the status of this discussion with the WG. I believe I've made a strong case that using CORS in a natural way can result in CSRF-like (Confused Deputy) vulnerabilities. There are several ways in which the pattern can manifest, but one of the simplest is A makes a request to B and includes some of the received data in a subsequent request to C. If credentials are used, A is applying all of its authority to identifiers selected by B. If B might be an attacker, there's a Confused Deputy vulnerability. There's nothing C can do to detect the attack server-side. Do WG members understand and accept the above? My impression from the discussion is yes, but people think it's a problem for Web developers to deal with and CORS has no responsibility here. Is that accurate? If so, can I convince WG members that we have a responsibility to provide easy-to-use *and* safe APIs to Web developers? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 21 April 2010 23:58:15 UTC