Re: CSRF: alternative solutions

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

I read it, and I must say that it is worse than I expected, but I
believe that most harm of login CSRF would be reduced if the user was
always informed of its present credentials.
In other words, every page should show visibly "You are logged as
XXX". This solves the PayPal problem for example, and may solve the
Search History problem (by saying "All your searches are being logged
to XXX.")

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

I meant to change only for the cases that browsers currently don't
send Referer (ie from data and ftp URIs). They could send Referer with
<scheme>://<host>:<port>/ or send a null Referer. In both case we
don't change the current semantics and we're backward compatible
(because if the server used to assume nothing and just live without
it, it would skip it)

>> Agreed on both (but we should define exactly what Origin:null and
>> Origin:empty mean and when both must be used)
>
> This is defined here:
>
> http://tools.ietf.org/html/draft-abarth-origin-00

Ok.

>>> 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:
>
> http://www.cs.purdue.edu/homes/ninghui/papers/csrf_fc09.pdf

That document was quite interesting, and also showed a case in which
both Origin and secret tokens fail. Anyway, it showed that heuristics
do work to determine if requests are intended or not, and in the
latter case the browser may strip authentication info or just ask the
user.

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

This depends on what exactly the text will be in the dialog and the
relative frequency of legitimate requests over all cross-site request
(ie the frequency of "Allow"s). I guess that many user will see the
dialog just a few times, and yet they will be protected, because they
will have clicked "Always from this site", that they have discovered
to be safe.

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

I don't agree with you. I think that ours are two completely different
points to see security, and I'm not sure they're compatible.

> Adam
>

Giovanni

Received on Tuesday, 9 June 2009 16:56:24 UTC