Re: CSRF: alternative solutions

Hi Giovanni,

On Mon, Jun 8, 2009 at 6:52 AM, Giovanni
Campagna<scampa.giovanni@gmail.com> 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

This is a good description of a CSRF attack.  There are some other
variations that might be worth considering.  For example, sometimes it
is profitable for attacker to forge cross-site requests to
http://www.mybank.com/login and thereby cause the user to be logged
into mybank.com as the attacker.  In addition to cookies, we could be
concerned about HTTP authentication, IP-based authentication, and
other authentication schemes.

> Solution #5 is possible, but requires a new header that proxies or
> firewalls may strip and current UAs don't send. In addition, it is
> possible that it will have the same flaws as Referer (which is very
> similar to Origin), like browser not sending it from https origins.

We can hope to improve on the Referer header.  In particular, the
Origin header is sent from HTTPS origins to HTTP URLs.  This is safe
because the Origin header (unlike the Referer header) leaks only the
host name of the HTTPS origin (not the path and query string), and the
host name is already leaked via DNS.

> Also, I'm not sure how it would interact with manual entering of URIs,
> like emails or IMs which say: "paste this into your browser address
> bar"

Two points here.  First, these send GET requests, and you've already
hypothesized (below) that the site doesn't make state-changing actions
on GET requests.  Second, if we wanted to send the Origin header for
these requests, we can send the value "Origin: null", which means that
the browser doesn't know where the request came from.  The site is
then free to reject (or accept) the request.

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

There have been a number of academic papers that have explored this
approach.  This has some really strange behavior.  For example, when I
follow a hyperlink from a web site to my Twitter feed, I no longer
appear logged in.  In general, you keep having to re-type your
password all the time because you're no longer logged in.

Some folks have explored heuristics for when to send cookies.  For
example, if you type something in the location bar, they'll send the
cookies because they think the request came from you (and not from
attacker.com).  I can try to dig up a few citations, if you like.

In general, this approach isn't able to prevent login CSRF because
login CSRF doesn't depend on the browser sending cookies to the
server.

> Lastly, solution #5 doesn't require any change in the security model

I presume you mean 4.  :)

> or in deployed web apps. The annonyance to the user could be avoided
> with something like "remember this choice". Yet, the user interface
> must make very clear where the traversal started, where it will end,
> and what information the UAs will send authomatically.
> This is the solution I prefer

I'm not sure what UI you have in mind here.  In general, we should be
careful about relying on the user to make correct security decisions.

> I hope that this will start a positive discussion, that could maybe
> improve existing and proposed CSRF prevention techniques.

Me too.  :)

Adam

Received on Tuesday, 9 June 2009 07:40:30 UTC