W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: CSRF: alternative solutions

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 9 Jun 2009 08:46:44 -0700
Message-ID: <7789133a0906090846t6a35bb85xac63b9bc8626014c@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: public-webapps@w3.org
On Tue, Jun 9, 2009 at 5:33 AM, Giovanni
Campagna<scampa.giovanni@gmail.com> wrote:
> 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)

I recommend reading
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf for
examples of why this is often sufficient for the attacker to perform

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

Change the Referer is a delicate matter.  Dropping the patch, query,
etc, impacts other uses of the Referer header.  For compatibility,
it's much safer to introduce a new header.  Because of some subtle
design decisions, proxies that strip the Origin header (were they to
come into existence) would harm only their clients, as opposed to the
situation with the Referer header where these proxies prevent everyone
from deriving CSRF mitigation benefits from the Referer header.  I
encourage you to read the paper referenced above for an explanation of
why this is the case.

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

This is defined here:


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

Here's one example:


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

We could evaluate the usability of this UI with a user study, but I
suspect users won't understand the consequences of this decision.
More likely user will click allow to get there work done.  It's hard
enough to get users not to click through warnings that say "this site
will install malicious software on your machine."

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

Perhaps, but we might be better off with a solution that doesn't
require the user to make a security decision.

Received on Tuesday, 9 June 2009 15:47:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC