No reason to keep this bug hidden. Bookmarklets are widely used though perhaps poorly understood from a security perspective.
This has apparently hit a critical mass at sites like Facebook. I'm going to take a shot a patch. Will report back soon.
Assignee: nobody → bsterne
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, also, Chrome reverts the address bar immediately after executing a JS URL as suggested in comment 3 -- which we've actually long considered a bug ( http://crbug.com/6888 ).
I'm glad to see some progress being made on this issue. :) The annoying part is that it is more of a design problem, so a technical solution will always have *some* shortcomings. We just need to make it cumbersome enough to make a user think twice. One interesting thought, forcing drag/drop or right click + bookmark link will at least cause the perpetrator to have to get the payload through one XSS filter. And surely 99% of the legitimate use-cases (for a normal person) are covered by those two interactions.
I guess Scratchpad, which just landed on mozilla-central, is supposed to be our new UI for "I want to type a script and execute it against the current page". But see bug 656544 comment 6 :(
(In reply to comment #14) > I guess Scratchpad, which just landed on mozilla-central, is supposed to be > our new UI for "I want to type a script and execute it against the current > page". But see bug 656544 comment 6 :( Why is Scratchpad any less susceptible to social engineering attacks than the location bar? /be
(In reply to comment #15) > (In reply to comment #14) > > I guess Scratchpad, which just landed on mozilla-central, is supposed to be > > our new UI for "I want to type a script and execute it against the current > > page". But see bug 656544 comment 6 :( > > Why is Scratchpad any less susceptible to social engineering attacks than > the location bar? Exactly. "Resistance to social engineering" was never one of its design criteria.
I'm not sure what you are arguing for? A more relaxed policy for the url-bar? A more restrictive policy for scratchpad? Moar warning in red bold letters? Something else?
(In reply to comment #21) > I'm suggesting this bug be morphed into a Core bug in some component. Sorry, duh -- this bug is meta. Want a blocking bug on the sandbox idea. /be
Asking users to make security judgements is a really bad idea. They will get it wrong every time.
The quality of user judgements about security actually depends on many things, including whether users have a good understanding of the consequences. In any event, users (i.e. people) really, *really* don't like looking like idiots amongst their friends, hence the key words: "send viruses to all your friends". (This is a social engineering virus problem --- you need to think like a social engineer, not a software engineer.) Anyway, this is just batting opinion back and forth. If people think the option is worth putting to the test, it's there for the testing.
I don't know if I must open a new bug for this request, but, please, insert a prefs in about:config to remove this patch. i understand the intent of this security restriction, but for no Facebook users this is a regression.
You can also re-enable this easily using about:config.
(In reply to Andreas Gal :gal from comment #31) > You can also re-enable this easily using about:config. How? In general, the very idea of removing a feature because of a possibility that user could be talked into abusing it, seems crazy. Isn't it the case that anything useful (and powerful) can be abused?
1. Why can't there be an pref for this? 2. Do you deny that given a sufficiently clueless user, any piece of useful and powerful functionality can be abused through social engineering? If that's going to be a threshold for removal (a real world example of someone being talked into doing something dangerous with the browser) then nothing is safe. How far do you intend to take this? At some point it has to occur to you that removing useful functionality is not the right approach or you'll reduce the browser to a single large friendly button that does nothing, but is 100% safe.
(In reply to al_9x from comment #36) > 1. Why can't there be an pref for this? > > 2. Do you deny that given a sufficiently clueless user, any piece of useful > and powerful functionality can be abused through social engineering? If > that's going to be a threshold for removal (a real world example of someone > being talked into doing something dangerous with the browser) then nothing > is safe. How far do you intend to take this? At some point it has to occur > to you that removing useful functionality is not the right approach or > you'll reduce the browser to a single large friendly button that does > nothing, but is 100% safe. Strawman much? We're not riding a grand slippery slope down into foolishness. As Jonas already mentioned in comment 35, we are responding to a significant number of our users actually being for-real harmed. Insulting them, or the developers trying to balance the flexibility of the platform with the responsibility we feel to keep our users from harm is not helpful.
This discussion is getting a bit out of control and unproductive. Can we bring some civility and respect back to this bug? Lets agree that this bug will go ahead as planned, understanding that its going to not make everyone happy. If you would like reverting this to be hidden behind a pref, please file a new bug report for thar functionality. I suggest any further debate on this matter to be spun off into a mailing list post. Thanks
The address bar has a long history, in most users' minds, as being a way to navigate, not a way to modify their browser.
(In reply to Jesse Ruderman from comment #49) > It was answered the first time Brendan asked it: > https://bugzilla.mozilla.org/show_bug.cgi?id=656433#c5 > https://bugzilla.mozilla.org/show_bug.cgi?id=656433#c6 > https://bugzilla.mozilla.org/show_bug.cgi?id=656433#c12 > https://bugzilla.mozilla.org/show_bug.cgi?id=656433#c22 Nope, that did not answer by citing actual attacks involving typing not pasting. Sorry, hypotheticals do not cut it. Worse, we diverged from other top-3-latest-rev browsers, for no real gain. Thanks for comment 52, pkasting. I think we should coordinate with Chrome and (if they are willing) IE folks to match by banning pastes only, and keep track of attacks to see whether typing becomes a thread. /be
(In reply to Matthew from comment #54) > Limiting many developers who are already very informed ... > If anyone can link me to a FireFox 5 download on the mozilla servers I'd > appreciate it. The well informed developers Firefox 5 download page can be found here: http://lmgtfy.com/?q=firefox+5+download
Brendan, we'd never fix any security holes with such an absurd burden of proof. Please reread comment 57 and remember that more people will use web browsers in the future than are using web browsers today.
I've received email today from a contact at a major social networking site, who let me know that Chrome users (a large enough set that it's worthwhile for attacker to differentiate) are now being told to "type a J and paste this string". This is exactly the attack we anticipated and it is why we chose to follow a more restrictive approach than the one advocated for in comment 52 (and elsewhere). I've invited my contact to comment here with more details once it's clear that it won't violate internal policies.
We're also corresponding privately with the same folks :).
I work on Facebook's security engineering team and have worked with Mozilla, Chrome, and IE on this issue. We've found these measures critical in fighting this type of scam. We have indeed started seeing variants that prompt the user to type 'j' then paste a string. An example is at hxxp://www.xtremeshack.com/immagine/i109533_facebookdnew.swf (this swf automatically copies an avascript: url to your clipboard). We don't have a lot of data yet, but here's a rough sense of effectiveness based on a sample of about 50k unique browsers posting via these scams. FX6 reduced expected bad posts by 85%, IE9 by 90%, and Chrome by 12%. I suspect that if we cleaned up false positives, FX6 and IE9 would be near-zero actual posts. Regardless, it seems Chrome users fell for this scam at close to the same rate as without the protection. Browser Pct of expected Firefox/3 97% Firefox/4 70% Firefox/5 65% Firefox/6 15% Chrome/12 151% Chrome/13,14 88% MSIE/8 101% MSIE/9 10% "Pct of expected" is actual_posts/(ie8_fx3_actual_posts/ie8_fx3_browser_share*browser_share) -- IE8 and FX3 are used as a baseline because they form the largest browser share without this sort of protection. This is based on about 50k unique browsers.
Thanks for the numbers, Scott. Chrome 12 at 151% makes me wonder if there is some other factor that is making the Chrome users in your sample generally more likely to make these types of posts, and the mitigations in Chrome 13 reduced attack effectiveness by 40% rather than 12%. I'm also curious what fraction of the scams in your sample are ones that attempt to bypass mitigations, and whether that fraction is roughly the same as the total fraction in the wild. As I noted in the email thread you had with the Chrome team, I'm also concerned about whether locking down the address bar more strictly will have any long-term effectiveness when attackers can instead instruct users to open the JS console. Of course we can then also lock all developer tools behind a command-line flag but that's something we'd really like to avoid doing (and then we need to eliminate bookmarklets, etc.)
Knowing whether this sample of scams was representative would definitely help. If we know that this is all "type j then paste" scams, then obviously Chrome is going to come off much worse, but if at the same time we learned that 0.001% of scams are like that, we would be less-inclined to panic :). And again, my ultimate concern is that we can do anything to the omnibox including preventing all script access from there and it doesn't address scams switching to the JS console.
No, this "type j and paste" scam is not very common yet, nor should we panic yet ;-)
(In reply to Mirek from comment #76) > I also don't see any long term security improvement thanks to this > limitation. Is it really more difficult to convince someone to press > CTRL+SHIFT+K or SHIFT+F4 or select sth in menu and then paste some code and > execute it? Probably the only solution is to disable bookmarklets, Web > console, Scratchpad, Error console and all but whitelisted addons for normal > users - but let's not forget about "power users" using Firefox & Mozilla > Suite from their beginnings. That's why I filed bug 664589.
You need to log in before you can comment on or make changes to this bug.