Josh Aas is concerned that once bug 304690 and bug 305374 are fixed (but before bug 286651 is fixed), users who encounter chrome:// URLs in AIM, IRC, QuickTime, or email will wonder why clicking the link didn't work and then paste it into Firefox's address bar. We agreed that it made sense to block the clicks from external applications silently, and warn users if they do paste a chrome:// URL into the address bar.
We don't think this vector is especially worrisome on its own, and we're past the point of adding strings.
Restoring lost blocking flag
No strings/UI changes at this point on the 1.5.0.x branch, thus we're not going to block on this, or even try to fix it.
10 years ago
Blocking, but the decision might be to not actually fix this as per comment 1. I need to sit down with johnath and understand this a little more. G30rgi, your point is well taken, and it makes me wonder if warning a user at this point will actually do any good. At the point where someone's pasting into a location bar to get a desired effect, do we have any hope of stopping them?
better warn than nothing. though disabling chrome and such is better imho.
10 years ago
removing in-litmus? until this is resolved, feel free to add it back at that time.
The amount of Facebook users doing this is on the rise. I've previously seen pages asking to select some text and paste it into the location bar. Today was different though, see the following page: http://www.facebook.com/IfSuperMarioWasMadeIn2010 This is an example of a page which gets users to press keys (Ctrl+C, Alt+D, Ctrl+V, Enter) to copy some hidden code and execute it. At the moment it is used to invite all friends to a page, but I don't think it will be long before something more sinister happens. Someone please provide a reason why this should be allowed for the average user. Bookmarklets could be special-cased.
 > which gets users to press keys (Ctrl+C, Alt+D, Ctrl+V, Enter) to copy some hidden code and execute it.  Bookmarklets could be special-cased. if you kill  and keep  alive probably the attacker's strategy will change to "make the js a bookmarklet and select it"
As Daniel points out, there seems to be an uptick in "paste this crap into the location bar!" social hacks - which makes me want to see a good solution here. Having said that, though, I don't think this blocks the release, though it would be lovely to see a fix.
This is also being discussed on the whatwg mailing list. My vote goes to having a whitelist on by default. Trying to disable the whitelist from the configuration **//strongly//** suggests the user that disabling the whitelist is insecure.
The whatwg thread starts with http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027246.html
Daniel: you could try YouTube or Vimeo...
Given the active attacks, I think we really need to do something here for Firefox 4. (Hopefully not a warning dialog!)
I don't think we'd want a warning dialog, and a whitelist seems hard to maintain. Feels like the easiest thing to do is: - disable JS in the URL bar by default - add a pref (maybe in Content) to allow people to turn it on Developers can find it and turn it on, most people never need to see it. Question, though: wouldn't that just morph the attack into "drag this into your location bar and click it"? How is this different from bookmarklets?
Malware/phishing protection *should* be used to handle blacklisting/whitelisting, since the engine for that is already in place. However this vulnerability adds something unique that should be separately targeted from black/whitelisting of source domain, specifically it is a wide open door for cross-site scripting attacks. Black/whitelisting is a cat and mouse game. The underlying vulnerability should be addressed too. Since there are already trusted registries for extensions and greasemonkey scripts, bookmarklets should have their own peer-reviewed registry too, and then whitelisting would be a whole lot easier.
Also the extra complication of tricking somebody into installing an ActiveX control and agreeing to the security implications meant that that was never a really viable way of infecting people's computers on a large scale. Just requiring someone to agree to give up security guarantees whenever they create a bookmarklet would be scary enough to dissuade lots of users from doing it.
It would be nice to see this pushed on a unified front, with all major browser vendors agreeing to standardize on disallowing JS URLs being pasted into the address field to prevent XSS attacks...
Victor: I filed an almost identical bug report and got a similar response. In the end they basically hinted that I might have more luck with Firefox :/
The current attacks don't just update a user's status, some of them actually mail themselves to all your facebook friends using facebook messaging -- hence the reliance on cookies.
djcater, please see the patches in bug 656433 and my comment on the first one ;)
(In reply to comment #43) > djcater, please see the patches in bug 656433 and my comment on the first > one ;) Yes, I've seen it now, thanks. Would have saved me a bit of time if someone had thought to link to that bug from this one earlier!
A warning dialog is WONTFIX in favor of bug 656433 and bug 656823, for the reason stated most clearly in comment 13. Beltzner's idea in comment 33 about suggesting Scratchpad is interesting. It might be reasonable to do in the future, but not with Scratchpad in its current state. The more general discussion seems to be in bug 527530 and on mailing lists.
See bug 656433.