[cap-talk] Confused Deputies in Capability Systems

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Thu Feb 12 04:26:25 EST 2009


Toby Murray wrote:
> On Wed, 2009-02-11 at 17:42 +0000, Karp, Alan H wrote:
>> Toby Murray wrote:
>>> Could you elaborate? How would you modify my web-browser-on-a-cap-OS
>>> example to avoid the confused deputy, or as you say "to perform the
>>> mapping [from URLs to capabilities] in the invoking context [i.e. that
>>> of the web-browser rather than the network service]"?
>>>
>> Here's what we did for legacy applications in e-speak.  We set up a
>> proxy for each external user at the gateway into the capability system.
>> Each proxy had the clist for its user.  The proxy mapped requests in
>> the legacy API, which used strings to denote resources, into the
>> e-speak API, which used capabilities.  Since the proxy only had access
>> to the user's capabilities, there was no way for the users to designate
>> rights they didn't have.  The worst thing the user could do was misuse
>> one of its own rights.
> 
> I understand completely.
> 
> I suggested something similar with the web-browser example: have the
> network service not hand back raw HTML but instead rewrite all URLs in
> the HTML to c-list indices and return capabilities to each resource.
> 
> This works for something like HTML but not for dynamically generated
> URLs as you might have in JavaScript.

If JavaScript code can generate an URL, then that code itself can be
confused (just as code running on the server could be confused if it
generates HTML / CSS / more JavaScript based on information that is
influenced by an attacker), but it isn't possible for it to be confused
about any more authority than that JavaScript context is given.

So, use an approach similar to e-speak with one proxy per site/origin
(using a fine-grained definition of origin), and only give a proxy
authority to dereference URLs with its own origin. This does not
eliminate all possible XSRF and XSS vulnerabilities, but the remaining
vulnerabilities will be those introduced by the site, not by browser
bugs. The site could use YURLs to avoid those.

-- 
David-Sarah Hopwood ⚥




More information about the cap-talk mailing list