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

On Mon, Dec 14, 2009 at 6:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Yes, I said "provides a way to eliminate". I agree that UM doesn't by
itself eliminate CSRF in a way that can't be undone by poor
application design. The UM draft we sent to this list covers this
point in the "Security Considerations" section. See the second to last
paragraph in that section:

http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0931/draft.html#security

That paragraph reads:
"""
Application designers should design protocols that transmit only those
permissions justified by the purpose of each request. These
permissions should not be context sensitive, such as "apply delete
permission to any identifier in this request". Such a permission
creates the danger of a CSRF-like attack in which an attacker causes
an unexpected identifier to be in the request. Instead, a permission
should be specific, such as "apply delete permission to resource foo".
"""

UM provides a safe substrate for application protocols that are
invulnerable to CSRF-like attacks. Without UM, this can't be done
since the browser automatically adds credentials to all requests.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Tuesday, 15 December 2009 17:40:40 UTC