[cap-talk] Security considerations for cookies

[David Wagner]

Mark Seaborn  wrote:
>Can't these attacks be addressed by the usual means of including a suitably
>unguessable secret in the URL or POST parameter (which can be checked
>against the cookie if you want to protect against URL leaks)?

No.  Parameters cannot prevent overwriting of cookies.
Implication: Whatever protocol you layer on top of protocols had
better be resilient to overwriting of cookies (or at least, to those
kinds of overwriting that can occur, given your threat model).

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.

>On further reflection, CSRF is different from the classical confused deputy
>compiler example:
> * In the compiler example, the attacker fully designates an object using a
>guessable filename in a global namespace.  More fully designating the object
>does not solve the problem.
> * In CSRF, the attacker specifies an object using a guessable name that is
>relative to an account.  More fully designating the object (using
>unguessable strings) is part of the fix.  (I am assuming that an object is
>something that is account-specific here, which is not always true.)

You've lost me here.  I don't see what distinction you're trying to draw.
I think classical CSRF *is* a confused deputy example, just like the
classical compiler example.

One fix to classical CSRF is to use a designator, knowledge of which
also suffices to prove authorization (note: this is not the same as
"fully designating").  That fix would have fixed the compilers problem,
and it would fix the web CSRF problem.  It doesn't mean it is the only
possible fix.  Speaking of "the fix" is nonsensical; there may be multiple
fixes, and "the fix" is not uniquely defined.

Perhaps you meant to ask whether Login CSRF is a confused deputy
problem?

>Login CSRF consists of two steps:
> * The attacker sends the login HTTP request.
> * The innocent page uses the resulting overwritten cookies.
>Which part is the CSRF?  The first step looks like a CSRF, but since it's
>not using any credentials in the request, I suppose it is abusing the HTTP
>server's ambient authority to overwrite the browser's cookies.

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 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.

Or, perhaps instead of asking "what's the CSRF?" you meant to ask
"is this a confused deputy problem?" or "where's the ambient authority?"
Those are interesting questions.

>> Web-keys have the same login CSRF problems because the attacker can
>> force the user's browser to navigate to the attacker's web-key.  Now,
>> the user might not notice that they're interacting with the server
>> under the attacker's authority.
>
>I would call this attack a kind of spoofing, rather than CSRF.

I'm tempted to agree.