[cap-talk] Security considerations for cookies

Adam Barth w3c at adambarth.com
Mon Feb 15 23:27:50 PST 2010


On Mon, Feb 15, 2010 at 11:15 PM, David Wagner <daw at cs.berkeley.edu> wrote:
> A related threat is that an arbitrary site may be able to delete
> all cookies, even of other sites.
>  http://kuza55.blogspot.com/2008/02/understanding-cookie-security.html
> Implication: Whatever protocol you use that uses cookies ought to
> be resilient to malicious deletion of cookies.  I'm not sure if this
> was mentioned in Adam's document.

Good point.  I've added this text:

[[
        <t>Finally, an attacker might be able to force the user agent to
        delete cookies by storing large number of cookies. Once the user agent
        reaches its storage limit, the user agent will be forced to evict some
        cookies. Servers SHOULD NOT rely upon user agents retaining
        cookies.</t>
]]

> FYI, you've left some important stuff out of your description of the first
> step.  The first step is that the attacker tricks the victim's browser
> into sending the login HTTP request.

I'm not sure there is a "trick" involved.  HTML contains an API (the
Form element) specifically for generating such requests.

> I guess that this probably gets labelled CSRF because it involves an
> attacker tricking the victim's browser into visiting some URL.  We could
> probably discuss whether it ought to be called CSRF, or whether it ought
> to be called a spoofing/trusted path problem.

For reference, here's a definition of CSRF I wrote in 2008:

[[
In a cross-site request forgery (CSRF) attack, the attacker disrupts
the integrity of the user’s session with a web site by injecting
network requests via the user’s browser.
]]

By that definition, login CSRF is indeed a CSRF attack.  Of course,
you might not like that definition.  :)

Adam


More information about the cap-talk mailing list