- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Tue, 9 Jun 2009 14:33:01 +0200
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps@w3.org
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