- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 9 Jun 2009 08:46:44 -0700
- 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 misdeeds. >> 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: http://tools.ietf.org/html/draft-abarth-origin-00 >> 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 >> 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. Adam
Received on Tuesday, 9 June 2009 15:47:44 UTC