Re: CSRF: alternative solutions

2009/6/9 Adam Barth <w3c@adambarth.com>:
> 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.

1) I cannot understand what advantages has the attacker into logging
the user with attacker's credentials. I expect that the user will
notice the different account used (for example in the web app
interface)
2) I used cookies in the example, but any state information
automatically sent is usable

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

This is one flaw, which can be corrected into Referer (dropping the
query, making path "/"). The other is firewall and proxies stripping
it: if they remove Referer, it is possible that they will strip Origin
as well.

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

Agreed on both (but we should define exactly what Origin:nully and
Origin:empty mean and when both must be used)

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

We can restrict this only to non-safe requests.

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

It may be useful for the discussion, thanks.

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

Yes, #4, sorry.

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

1)
========================================================
| This website, "Title of malicious page", at          |
| http://www.dangerous.com/index.html                  |
| tried to perform a POST request to                   |
| http://www.mybank.com/pay?to=attacker                |
| A similar site was last seen as                      |
| "My bank account - userId - Transaction Confirm"     |
|                                                      |
| This request includes authentication info, and       |
| thus may involve processing not desired on the       |
| behalf of the user (for example sending an email)    |
|                                                      |
|         ((Allow))          ((Deny))                  |
|                                                      |
| ( ) Always for these origins only                    |
| ( ) Always from www.dangerous.com                    |
| ( ) Always to www.mybank.com                         |
| ( ) Only this time                                   |
========================================================

2) On the contrary, it is the user the only person who knows if it
clicked intentionally, and wanted to perform a cross-site request.

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

Giovanni

Received on Tuesday, 9 June 2009 12:33:34 UTC