A new class of trojan horse attack has been discovered which affects practically all browsers, and most Web sites which allow individual users to enter data (such as message boards, for example). See URL for details. Briefly, someone posts an innocuous-looking link to a page, and you click on it; the linked page, however, redirects you to an URL which does something malicious with your user account on some server -- such as posting an embarrassing comment on a discussion board, or deleting your Web site using Web-based server administration, or whatever. A simpler form of the attack is to provide a link which is not even a redirect, but a link to the actual damaging URL, and to use JavaScript to mimic the client's feedback for a legitimate link (e.g. putting a fake URL in the status bar). Individual servers can implement a number of partial fixes to this problem, based on the HTTP referrer, cookies, and so on. But every site in the world can not be trusted to do this, so Mozilla should do its bit to fix the problem too. So, I recommend that whenever a user is directed --- to an URL which requires authentication, --- from a non-local source which did not require that same authentication, e.g. --- to an URL which deletes my Hotmail Inbox folder (if I have one) --- from an URL which did not require my Hotmail authentication, AND the required authentication has been cached (either permanently, or for the current session) by the browser, THEN a dialog should be displayed: +--------------------------------------------------------+ |[] Security warning ::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------+ | /!\ To open this address, Mozilla needs to use your | | `-' stored login for `{Realm}' at`{server}'. | | | | If you did not intend to use your `{Realm}' login | | now, you should select Cancel. | | | | ( Help ) ( Cancel ) (( Continue )) | +--------------------------------------------------------+ This wouldn't fix the whole problem (such as the recent example on Slashdot where someone posted a link which, when clicked by any subscriber, posted a comment of arbitrary content which appeared to be from that subscriber); but it would be a good start. You probably want a list of trusted source domains too, along the lines of the `No proxy for:' list in prefs -- so that corporate firewall users don't have to be presented with this dialog each and every time they follow a link which goes from their Intranet (which doesn't require authentication) to the world outside (which does).

See also bug 38008.

Gagan, I heard you know about HTTP authentication. This is a security exploit involving redirects and authentication - could you please take a look?

*** Bug 40132 has been marked as a duplicate of this bug. ***

Waitasec. My original suggestion would work for cases using genuine HTTP authentication, but it wouldn't work for the usual (Hotmail, Slashdot, etc) cases of just using cookies for login. Hmmmm. Ok, the analagous way of dealing with it for cookies would be: whenever a user is directed --- to an URL where the HTTP request reads a particular existing cookie, --- from a non-local source which did not read that same cookie, show a similar dialog. And you'd want to have a checkbox to turn the dialog off on a cookie-by-cookie basis, for those cookies where any use of the cookie was harmless. Come to think of it, you'd probably want that for HTTP authentication, too. So, take two. For HTTP authentication: +--------------------------------------------------------+ |[] Security warning ::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------+ | /!\ To open this address, Mozilla needs to use this | | `-' stored login (HTTP authentication): | | server [ ] | \ non-editable, but | realm [ ] | / scrollable, fields | | | If you did not intend to use this login now, you | | should select Cancel. | | | | [*] Always warn me about using this login | | (this can also be changed in the Xyz Manager) | | | | [?] ( Cancel ) (( Continue )) | +--------------------------------------------------------+ And for cookies: +--------------------------------------------------------+ |[] Security warning ::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------+ | /!\ While opening this address, Mozilla has been | | `-' asked to send this stored data (cookie): | | server [ ] | \ non-editable, but | name [ ] | / scrollable, fields | | | If you did not intend to use this data now, you | | should select Don't Send. | | | | [*] Always warn me about using this cookie | | (this can also be changed in the `Cookies' | | category of Preferences) | | | | [?] ( Don't Send ) ( Cancel ) (( Send )) | +--------------------------------------------------------+ Note that the second dialog doesn't actually show the value of the cookie -- as a guard against the case where a malicious co-worker sends you an e-mail message containing such a link, and then tries to read over your shoulder as you follow the link. The difference between `Don't Send' and `Cancel' in the second dialog is that `Don't Send' continues the HTTP request without sending the cookie, whereas `Cancel' cancels the HTTP request altogether.

Further thoughts: * This attack can be called from JavaScript, not just from redirects. This calls for two changes in the dialogs: - instead of the server name, the dialogs should probably show the actual address being accessed, providing the user with some additional information about what the access is actually trying to do (this would probably have been a good idea anyway); - the text `To open this address' or `While opening this address' should be deleted, since the attack may be called from JavaScript when (as far as the user is concerned) the main `address' has already been opened. * It would still be up to discussion sites such as Slashdot to prevent posters from including JavaScript in their posts -- otherwise a poster could post an attack on the same site as the one on which the undesirable effect happened, and this dialog would never appear (because the source and the destination would be at the same server). Here's some useful linkage (mostly from bug 40132): * <http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan> (original article) * <http://lwn.net/2000/features/Redirect.phtml> (a general summary) * <http://www.linuxnews.com/news/?1,145> (another general summary) * <http://slashdot.org/comments.pl?sid=00/05/19/190219&cid=42> (example of attack -- there's a more friendly example on Slashdot somewhere, but I can't find it) * <http://weblogs.oreillynet.com/edd/stories/storyReader$52> (possible solutions discussed) * <http://weblogs.oreillynet.com/edd/discuss/msgReader$54> (a suggested need for some measurement of `intent' when doing something with authentication).

Martijn and I posted some comments on bug 40132 (marked as dup) that I think are very relevant here. Martijn suggested that we tell sites what type of user interaction led to the loading of the site; I suggested that mozilla filter all cross-site form submissions (including GET forms, but with a separate "ignore this warning" setting). Matthew's dialog only seems to address the case where the victim has a cookie or http auth. It doesn't help with sites that accept anonymous comments, or sites that accept comments based on self-reported name and display your IP address, if the sites don't check the referrer for form submissions. > from an URL which did not require my Hotmail authentication Does the browser know that *.hotmail.passport.com requires the same authentication that *.hotmail.msn.com requires?

I said `Mozilla should do its bit to fix the problem', but Mozilla will only be able to go so far. Here's why the situations cited by Jesse can't be guarded against in the client. > Martijn suggested that we tell sites what type of user interaction led to the > loading of the site We do this already, through the HTTP referrer. If sites need more detail than that, there's not much we can do without extending the HTTP standard. > mozilla [should] filter all cross-site form submissions (including GET forms, > but with a separate "ignore this warning" setting) There are far too many ordinary URLs which are both (a) of the GET type and (b) often linked to from other sites, for something like this to be useful. Examples: - Bugzilla bug reports - ZDNet stories - search engine results - CNet stories - Deja.com Usenet articles - most NetCenter links. Even with the option for turning it off for individual servers, you'd be turning it off more often than you'd be actually using it. So dialog fatigue would set in -- the user would start clicking `Continue' automatically, making the dialog useless. > Matthew's dialog ... doesn't help with sites that accept anonymous comments, And the damage would be much less for such sites -- such an attack would not do anything more harmful than post an anonymous comment claiming to be from you, something which could be easily refuted since it was posted anonymously. > or > sites that accept comments based on self-reported name and display your IP > address, if the sites don't check the referrer for form submissions. Such sites are broken -- if Mozilla tried to cater for them then it would be too annoying when visiting other sites, and the warning effect would be lost (as described above). > Does the browser know that *.hotmail.passport.com requires the same > authentication that *.hotmail.msn.com requires? No, and that's a good thing. On both the big-brother level and the practical security level, Mozilla should be encouraging storage of global passwords in your local Wallet or Keychain, not on a server like passport.com.

Heh. Just when I post a bug on the issue it turns out someone else already did this for me. Thanks Matthew. This problem will not be easy to fix. It comes in several forms, involving redirects, tricking users into clicking an image, a link, a button, or using Javascript. I can also think of several scenarios where the Referere field does not give enough contextual information for the server to be able to determine wether or not the request is legitimate. Also, the Referer field is seen as revealing privacy sensitive information, and is filtered out by some proxies or firewalls, often outside the control of the affected user. I suggested that browsers start giving some more contextual information, information that is not privacy sensitive, and which can help in many situations. I do not claim that with it we can fully mitigate risk in all possible scenarios, just that it would help. Again, this is not a problem easily solved. Discussion on this issue is needed.

Matt, I don't think you got many of my points. Maybe my wording sucks. >There are far too many ordinary URLs which are both (a) of the GET type and >b) often linked to from other sites, for something like this to be useful. Good point. Since (someone?) recommends that GET forms be used for searches and displaying information and POST forms be used for altering data, it would be reasonable to not block cross-site GET forms. Mozilla should (IMO), however, aggressively filter cross-domain posting. That means hotmail.com should give a warning the first time, and allow the user the option of saying "allow hotmail.com to post to passport.com". You say "these sites are broken" in response to one of my examples. This is not an adequate response, this bug is *about* protecting broken sites and users of those sites. A huge percentage of dynamic-content sites are vulnerable, and some fairly recent (but not current) versions of apache itself were as well. Many "anonymous" comments sites do log ip addresses. I can make it look like one of the visitors on my website is attacking another website. Also, I can flood another site from various IP addresses without the attack being traceable back to me. This problem will mostly go away if major browsers block cross- site posting. Another problem with only enforcing the POST policy for sites where you have a cookie/auth is that you might want to get a cookie/auth later, or might assign you a cookie when you make your first post. Sites that use cross-domain posting, while usually not malicious, are relatively rare, and more importantly, are indistinguishable from malicious sites doing the same thing. Hotmail.com should show a warning the first time. Note: bugzilla is not excluded from the "broken sites" set. It accepts GET forms for modifying data, doesn't check for cross-site posting, and only escapes URL parameters on about half of the commonly used pages. The last two are at least partially covered by dependencies of bug 38852. <end unconnected rant>

Jesse, you're right. The bit about cross-domain POSTing flew completely over my head. Ok, take three -- incorporating fixes for all the problems I've thought of so far (including the problem where the first sentence of the dialog needs to give some idea of the purpose of the dialog) ... For following a link/redirect/script from a non-authenticated document to an authenticated one: +--------------------------------------------------------+ |[] Security warning ::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------+ | /!\ Mozilla needs a different login to open the | | `-' address | | [http://cantsb.canterbury.ac.nz/transfer_funds.c] | | | | To open this address, Mozilla needs to use the | | following login (HTTP authentication): | | Server: [cantsb.canterbury.ac.nz ] | | Realm: [ITS ] | | If you did not intend to use this login now, you | | should select `Cancel'. | | | | [*] Always warn me about using this login | | | | [?] ( Cancel ) (( Continue )) | +--------------------------------------------------------+ For following a link/redirect/script from document A to document B, where document B requires a cookie which document A did not: +--------------------------------------------------------+ |[] Security warning ::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------+ | /!\ Mozilla has been asked for a different cookie | | `-' while opening the address | | [http://webmail.com.foo/act/DELETE/folder/Inbox/] | | | | Mozilla has been asked to send the following | | stored data (`cookie'). | | Server: [webmail.com.foo ] | | Data: [user_id ] | | If you did not intend to use this data now, you | | should select Don't Send. | | | | [*] Always warn me about using this cookie | | | | [?] ( Don't Send ) ( Cancel ) (( Send )) | +--------------------------------------------------------+ And finally, for following a link/redirect/script which POSTs data from one server to another: +--------------------------------------------------------+ |[] Security warning ::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------+ | /!\ Mozilla has been asked to post data to a | | `-' different server to open the address | | [http://slashdot.org/post_comment.cgi ] | | | | Mozilla has been asked to post the following | | data:___________________________________________ | | [Name_________|_Value___________________________] | | |user_id | davidr8 |A| | | |comment | STUPIDEST POST!!!!!1 |:| | | |_____________|_______________________________|V| | | If you did not intend to send this data, you | | should select Cancel. | | | | [*] Always warn me about posting from this server | | | | [?] ( Cancel ) (( Send )) | +--------------------------------------------------------+

I'm concerned about taking a user-warning based approach to this problem. As Matthew touched on above, there is a big danger that "dialog fatigue" will render these warnings useless over time. I think that in the end to really solve this problem in a satisfactory way web clients and servers will need to cooperate in a way that (with or without client-based warning dialogs) provides servers with enough context to determine if a request is appropriate. As Matthew also noted, this may be hard without extending protocol expectations. That may well be the case - but just because it's hard doesn't mean it shouldn't be done. The more I think about this the more convinced I am that this is the more promising direction (though I dont pretend to be clear about the details of that direction yet). The server will need to be involved in this process, because any arbitrary decisions made by client(s) will restrict the kinds of things you can do securely on a server. A case in point: the current proposals tend to be concerned about security across a "domain" or "servers". While a domain or server is certainly an example of _a_ security context, there are much finer-grained security contexts in use on the Web. And what we are really talking about here is not even totally confined to a _security_ context, but to context in general. The current Web architecture provides ways for foreign objects to force you into taking unintended actions, and provides no reliable standard ways for either the client or the server to discover enough about the context to determine if the action is suspicious. FWIW, the default security for javascript suffers from the same lack of context IMHO. Current clients take measures to prevent "cross-site scripting" but the idea of "site" here is quite literal, "hard-coded" (in the client implementations) and too coarse-grained. What about a "site" like a GeoCities or any number of similar web presences where many, many people and/or organizations share the same site? The cross-site scripting protection currently provided by clients does not protect these folks. I think that it would be a poor answer to say "well, sites like that will just never be secure, so don't build sites like that".

Brian, Martijn, Jesse: If you want a more thorough, protocol-based solution to this kind of trojan, you should reopen bug 40132, mark this bug as a dependency of that one, and carry on the discussion there. Or even better, discuss the problem in n.p.m.security, so you can then file specific bugs which will get fixed rather than using Bugzilla as a discussion board. This particular suggestion is a relatively cheap (in development hours) attempt to curtail the vast majority of these attacks, right now. Yes, I do realize it won't work with GeoCities, but I calculate that the ratio of {risk of one GeoCities site attacking another} to {stuff that could be done about that problem right now} is very low. And no, I don't think it will cause dialog fatigue by having a high rate of false positives, since (a) it doesn't operate on GET requests and (b) it is possible to turn the warnings off on a server-by-server basis. Nominating for RTM -- these attacks are already appearing in experimental form on sites such as Slashdot, so it's only a matter of time before they manifest themselves elsewhere. And CCing verah, just in case she can find anything wrong with my dialog text.

Okay, marking dependency, reopening other bug.

Fixing dependencies ...

... done

Assigning Qa to czhang.

Interesting! I'd like a chance to rewrite the dialogs slightly, just so the "average" person out there will know what's going on and perhaps have a clue as to what to do about it. What's the target milestone for this?

IMO, this is all a case of bad server-side design. Classic examples of this class of error include using GET rather than POST when submitting passwords (and hence getting passwords placed into the history list :-( ). Sites which take actions based solely upon a visit with an appropriate URL (where actions are defined as posting email, deleting accounts, changing privledge on access to things, etc. etc.) have fatal flaws. If we try to protect people from the poorly designed sites, we'll end up harming the usability of well designed sites. As an example, the New York Times requires certain logins for use. A lot of folks email out pointers to articles in the New York Times. If we add this protective feature, we'll soon begin bother folks with extra dialogs as the visit the New York Times. Considering that there is even an attempt listed above to block cookie-based-authentication, we'd also end up slowing all sorts of visits to advertising sites that have already set a cookie on the user (there is no way to distinguish identifying cookies from authentication cookies :-( :-( ). In fact, since Netscape sets an id cookie historically, we'd end up issuing a security warning every time anyone tried to link to a Netsacpe site :-( :-(. My bet is that 90% of all commercial sites set some cookies... so all such sites would now have security warnings on visitations :-/. The big follow-up RFE would be to have a way to turn off this feature. Bottom line: Please think carefully about such RFEs. Unless there is a big gain, and usability, the security we gain may come in the form of folks not being willing to use our product :-(.

This isn't an easy issue, as already stated in #40132. This bug is a concrete proposal for solving one problem, but the root cause of the problem is discussed in #40132. The servers aren't entirely to blame, the current set of information sent by the browser doesn't contain enough context to always fully determine the context of a request, which would help the server decide if the request is genuine. If more contextual information was available, this particular RFE may not be necessary at all, the server can then more accuratly assess the situation.

Jim: I guess you're right about URL-dependent servers being too broken to bother fixing. Ok, so let's apply the warnings just to redirects, IMGs/OBJECTs, and scripts, and not to links. That removes the dialog from well-behaved servers like nytimes.com (though whether requiring registration at all is `good behavior' is obviously a matter of opinion). It doesn't solve the problem for badly-behaved (but non-malicious) sites like netscape.com, which redirect you between half a dozen different places when you click on a link; but if you visit sites like that regularly, you can check the `Always warn me about using this cookie' checkbox. This will be getting the 4xp keyword soon ... Microsoft is about to offer the same dialog for cookies in IE 5.5. See <http://microsoft.com/presspass/images/features/07-20cookies.jpg>. (And IMNSHO, my dialog is clearer than IE's one.:-)

Removing nsbeta3 and retargeting Future, for the following reasons: 1) This bug is mainly the server's responsibility to fix 2) Our security UI policy is for as few warning dialogs as possible. I'm not convinced these things really help security (although they may reduce Netscape's liability). 3) Adding new dialogs could be destabilizing at this point in the product cycle. I think the ratio of work to benefit here is too high to be working on this problem right now.

*** Bug 51691 has been marked as a duplicate of this bug. ***

Mass changing QA to ckritzer.

This issue is closely related to the recently reported drive-by pharming security threat. in that case, the illegitimately accessed web site is the user's home router. See https://bugzilla.mozilla.org/show_bug.cgi?id=371598 for more details.

I'm not sure which of XSRF related bugs is the correct place for this comment. I was thinking that a large number of the vulnerabilities can be mitigated by not sending cookies by default if the referrer is on a different domain from the URL being fetched. But proceed with loading the URL as usual. I guess it may break some sites. But I think the way to find out what it breaks is to introduce the functionality to suppress cookies in those cases. There should be a setting to turn it on and off, and at first it should probably use the old behaviour by default. This issue has been open for a decade. And by now I think we can agree that getting it fixed on all the vulnerable sites is just not going to happen. Even security aware users are bound to need to use vulnerable sites once in a while, and currently it seems the only safe way to do so is to: 1. Ensure nothing else is open while logging in to the vulnerable site (restart the browser before just to be on the safe side). 2. Stick to just that one site for the session. 3. Log out when done. 4. Restart the browser again, just in the site left some sensitive session cookies even after logging out. It is possible to use sites with XSRF vulnerabilities safely, but it requires a huge amount of discipline from the users and severely reduces the usability of the browser when you can't open other tabs to look up documentation while logged in to a vulnerable site. The defence in depth principle suggests this should be fixed both on the client and on the server side.

I strongly support this RFE. @Jim: This isn't actually bad server-side design. A server receives a POST request that has the correct cookies or HTTP AUTH for a validly logged-in user. The fact that the user didn't intend to make the request, or even know about it, is not apparent. Actioning that request is not a broken thing to do. I've recently been implementing protection against these threats at work, and even with a framework that specifically supports this, getting it right is non-trivial. Also, the proposed dialog would not be significantly more fatiguing than the existing 'Ask me every time' dialog for cookies, particularly if it applied only to POST requests (which is reasonable). There's lots of synergy, too, because if you're selective about which domains can set cookies, you shouldn't often see the cross-site cookie dialog. But like the original cookie dialog, it should probably be off by default. At present, if I browse to evil.com, it can send arbitrary requests to bank.com (using JavaScript, IFRAMES, redirects, etc), and if I happen to be logged in, then the browser will happily attach the appropriate cookies or auth so that bank.com thinks those requests came from me. The problem is made worse because Firefox shares session across all browser windows, so there's no way to isolate bank.com without shutting the browser down and restarting it. That sounds to me like bad browser design. Currently I have to rely on highly invasive addons like NoScript and RequestPolicy to protect against holes like this. I personally am happy to make that tradeoff to keep my security, but very many users are not. Incorporating an optional warning like this would allow security-conscious-but-not-tech-savvy users to be safer. I would suggest wording similar to: "The site foo.com is trying to send a request to bar.com. You currently have one or more cookies for bar.com, which could mean that you are logged in to bar.com. If you allow this request to use your cookies, then bar.com will think that the request came from you. Do you trust foo.com to take actions on your behalf at bar.com? x Remember my decision for this website Yes (send cookies) No (send without cookies) Block request

HTTP AUTH dialog would be similar, but shorter: "The site evil.com is trying to send a request to bank.com. You are currently logged in to bank.com. If you allow this request to use your logged-in session, then bank.com com will think that the request came from you. Do you trust evil.com to take actions on your behalf at bank.com? ... "

The recently-published CRIME attack against TLS could be defeated by this RFE, because when the attack script started to send requests to the target site, the user would be alerted and given the option to anonymize or block the requests.

And now we have the BREACH attack against TLS, which allows an attacker to extract sensitive data from encrypted HTTP responses. Again, this RFE could defeat the attack, because if the request is anonymized, then the response will not contain anything sensitive. I think it's clear by now that from a security standpoint, the idea of automatically attaching cookies to any arbitrary request, made by any website, is broken. Cookies have become a 'something you have' authentication factor, and that authentication should not be available for any random website to exploit without even notifying the user.

Can something be done about this? Cookies may have started life as mere site preferences, but now they represent authentication. Blindly attaching the user's authentication to any and every potentially-malicious cross-site request is begging for trouble. Let's at least do something about the worst-case scenario: an unencrypted site (attacker.com) wants to send a cross-domain POST request to an encrypted site that has set cookies. That's pretty clearly suspicious behavior. There should be at least an about:config preference to block this or prompt the user.