Re: CSRF: alternative solutions

On Mon, Jun 8, 2009 at 3:52 PM, Giovanni Campagna wrote:
> As I understand from various discussions here and from articles
> around, I've learned that CSRF is a security leak which involves:
>
> 1) user visites http://www.mybank.com/login
> 2) the server sends a cookie, call it MyBankSID, with the login information
> 3) user visites http://www.dangerous.com/ within the expiration time of cookie
> 4) the user clickes a link (or sends a form) to
> http://www.mybank.com/pay?to=hacker
> 5) the browser sends MyBankSID cookie, which grants access to user's
> bank account
> 6) money goes from the user to the attacker
>
> To stop CSRF, we need to stop this algorithm at one of these steps.
[...]
> We can stop it at 4), preventing the user agent from sending
> automatically state information when the request is originated from a
> foreign (and possibily untrusted) origin. This means that cookies are
> not sent for requests that are not same-origin.
[...]
> All of these solution have pros and cons:
[...]
> Then we have solution #4. This may hurt web apps that currently
> require sensitive cross-site requests, but I'm not sure that there are
> any, and they could work with automatic redirection to a login page.
> Architechturally, assuming that the UAs keeps authentication info and
> automatically sends it is a bad idea that we should not encourage, and
> so designing web services that require this.

This would rule out all SSO mechanisms:
1. user visits mail.google.com
2. given that it is not authenticated (no cookie or stale cookie
value), user is redirected to www.google.com/accounts
3. user is already authenticated, so it is redirected back to
mail.google.com with a new SID (in the query-string)
4. mail.google.com sets a cookie to authenticate user for later requests

I took google.com apps as an example, but ti works the same with, e.g.
JA-SIG CAS and probably any other SSO (including OpenID).

With your proposal, the redirection to www.google.com/account would
not send the cookie and thus would require the user to
re-authenticate, defeating the SSO.

Would it also mean that the browser "forgets" about the previous
cookie that was set by www.google.com/accounts when the user
authenticated first (let's say for using google groups or google
docs)?


Have you read http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf
? There are other CSRF threats, such as session fixation.


-- 
Thomas Broyer

Received on Monday, 8 June 2009 22:28:16 UTC