On Wed, Apr 21, 2010 at 2:43 PM, Dirk Pranke <dpra...@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