On Mon, Dec 14, 2009 at 4:52 PM, Tyler Close <[email protected]> wrote: > On Sun, Dec 13, 2009 at 6:15 PM, Maciej Stachowiak <[email protected]> wrote: >> There seem to be two schools of thought that to some extent inform the >> thinking of participants in this discussion: >> 1) Try to encourage capability-based mechanisms by not providing anything >> that lets you extend the use of origins and cookies. >> 2) Try to build on the model that already exists and that we are likely >> stuck with, and provide practical ways to mitigate its risks. > > My own perspective on this is: > 3) In scenarios involving more than 2 parties, the ACL model is > inherently vulnerable to CSRF-like problems. So, for cross-origin > scenarios, a non-ACL model solution is needed. > > The above is a purely practical perspective. When writing or auditing > code, UM provides a way to eliminate an entire class of attacks. I > view it the same way I do moving from C to a memory safe language to > avoid buffer overflow and related attacks.
For what it's worth, I'm not sure that "eliminating" is correct here. With UM, I can certainly see people doing things like using a wrapping library for all UM requests (very commonly done with XHR today), and then letting that library add the security token to the request. If such a site then retreives a URL from a 3rd party and uses the library to fetch, or POST to, a resource, that could lead to the same confused deputy problems. I agree that UM lessens the risk that this will happen though. And it eliminates the ability for anyone to blame the browser vendor when it happens. / Jonas
