[cap-talk] Confused Deputy gets a new name in Web 2.0 lingo

Tyler Close tyler.close at gmail.com
Mon Oct 16 23:12:21 CDT 2006


On 10/16/06, Ka-Ping Yee <cap-talk at zesty.ca> wrote:
> On Mon, 16 Oct 2006, Tyler Close wrote:
> > "A cross-site request forgery is simply a confused deputy attack
> > against a website. The deputy in the bank example is the bank website,
> > which is confused into misusing Bob's authority at Alice's direction."
>
> Yes, that's what i added.
>
> > If so, I think it needs to be amended. The deputy role is being played
> > by the web browser, not the bank website. The browser has been
> > instantiated with some of the user's authority (the bank credentials)
> > and some of the visited site's authority (the attack site).
>
> I think it could be seen either way, depending on what you believe
> the intended purpose of the cookie to be.  If you see the cookie as
> an authorization, then the web browser is inappropriately providing
> that authorization and it is the confused deputy.  If you see the
> cookie as user authentication (which is how i see it), then the bank
> is inappropriately exercising the user's authority when that
> authorization has not been provided, so it is the confused deputy.

The Confused Deputy attack occurs because authorizations are not
reified, but are instead inferred based on the identity of the
requestor. So I don't understand what you mean about seeing the cookie
as being an authorization in a Confused Deputy attack. There are no
reified authorizations in a Confused Deputy attack.

In a Confused Deputy attack, the deputy is a composite of two or more
identities. The attack occurs because the deputy is unable to express
what part of the authority coming from which identity should be
applied to what part of the current request. Identity-based access
control does not provide a means for expressing these distinctions.

> I chose the latter interpretation because i think most people see and
> use cookies as a form of authentication, and it fits better with the
> proposed solutions on that page (e.g. have the website put a session
> token in a hidden form element).

I don't see a choice here. Perhaps you could clarify by explaining how
the bank's website can be seen as a composite identity, and of which
identities.

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/


More information about the cap-talk mailing list