Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 4:52 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Sun, Dec 13, 2009 at 6:15 PM, Maciej Stachowiak <mjs@apple.com> 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

Received on Tuesday, 15 December 2009 02:15:21 UTC