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
Bug 358266 reminded me about this while I was in an anti-security-dialog mood, so I thought about how to fix this without adding a new security dialog that won't make sense to 99% of the users who encounter it.
* For data: URLs, the URL should just be loaded with a null principle.
* chrome: URLs aren't as worrisome, IMO, but maybe they could get a (non-privileged!) replacement page similar to the one for about:config.
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.
tricking a user via social engineering means to paste 2 urls in a new tab leads to code execution:
and then in the same location pasting
in case some chrome trusts parameters from location.href this may be done with one paste.
having in mind the amount of malware i receive users do stupidier things than pasting in location bar.
and this poses the question: is pasting in the location bar safe.
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.
removing in-litmus? until this is resolved, feel free to add it back at that
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:
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 Georgi points out, we'll also need different UI for bookmarks (bug 371923).
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.
(In reply to comment #11)
> inherit principals for data: in the address bar). We can show something in the
> error console that mentions a hidden pref, but the default should be that
> nothing happens (certainly not a yes/no dialog).
+1 ... the social engineering "worms" spreading around Facebook right now are a PITA, and a warning will be lost on users who will tend to click through the warnings to get to whatever is on the other side.
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
+1 -- I started the whatwg thread after getting 1-2 of these facebook worms per week from clueless friends.
Unfortunately most people don't have a clue that they have been spreading these worms because the worms usually show you what they say they'll show you after mailing themselves to everyone in your friends list. And there's so much junk shared on facebook anyway that very few people actually question why someone would be sharing the link with them. As a result, the fan page associated with these worms usually gets tens of thousands of "Like"s before anybody reports it as spam.
Slightly modified repost of my suggestions on the whatwg thread (written about Chrome, but the same principles apply to Firefox):
(1) The same warning should be given when dragging bookmarklets to the addressbar as is given when installing .crx extensions.
Given the success of these exploits so far on facebook, the use and nefariousness of them will likely only increase.
I took a screencast of a recent Facebook page that was doing this if anyone wants it e-mailed to them (it's too big to upload here and tinyvid.tv didn't accept it for some reason).
I also copied the code that would be run if you followed the instructions to the end (which it seems tens of thousands of users did).
If anyone can fully decipher that I'd be interested to see it (not sure if it's really relevant to this bug though, so probably best to e-mail it).
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?
I agree that disabling js in the location bar and letting developers switch it on as needed is the most sane default.
(In reply to comment #22)
> It will be easier to create a sensible whitelist for bookmarklets than for
> drag/drop operation the actual originating site is always known.
I presume that such a whitelist would include my website, and Jesse's website, and all the new web service sites that come out and provide bookmarklets for users, and ...
(I don't think it's easier, is what I'm saying ;) )
Why can't the normal malware/phishing protection handle this type of attack?
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.
*** Bug 655099 has been marked as a duplicate of this bug. ***
Margaret: thank you for pointing me to the right bug, I'm sorry I didn't find it when I did my dupe search.
More complex solutions for bookmarklets can be figured out while scammers rewrite their instructions to target bookmarklets or the Web Console.
Thank you so much!
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...
Luke: I haven't had much success with Chrome -- http://crbug.com/81697
I'm sure they'll follow suit if both FF and IE fix the problem, though. And, given the current market shares, having FF and IE fixed would take care of most of the spam.
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 :/
Rob/Patrick: now that scratchpad has landed on nightlies, do we think that it might be a better way for developer-users to enter direct JS URIs into the product?
FWIW, I still wonder about the value of a pref-based approach here. As per comment 6 and comment 21, though, I can't help but wonder if it's not just a band-aid. If someone's convinced me to copy and paste a URI in my location bar, would I not just treat any warning as a "whatever" button? Further, would I not follow instructions to first flip a preference and then paste the URI?
I would almost rather see something like:
[ Copy to ScratchPad ] [ I don't understand ]
if the user clicks "I don't understand", then just ditch the string, don't copy to the scratchpad, wash your hands and walk away :)
(In reply to comment #33)
> If someone's convinced me to copy and paste a URI in my location bar, would I > not just treat any warning as a "whatever" button? Further, would I not follow > instructions to first flip a preference and then paste the URI?
Mike, see comment 9 for an example of how most of the attacks I've come across work. They don't explicitly ask the user to paste something into the location bar. Ctrl+C, Alt+D, Ctrl+V, Enter (with animations to draw your attention away from the briefly highlighted URI in the location bar).
Bookmarklets could get a dialog, or be left as is for now (bookmarklets exist to save time, having a warning every time would probably get annoying). I don't think they pose the threat that the many social media human-hacks do at present.
Web developers can use the console, which has advantages over directly using the location bar anyway (don't lose the current location, warnings and exceptions displayed).
Personally I would be fine completely disabling both bookmarklets and js URLs, most users don't even know what either function is.
(In reply to comment #38)
> bookmarklets are things that interact with the contents of the current page
Brendan specifically suggested the sandbox idea for typed and pasted URLs only ("and only in this case").
The scripts currently run with the same privileges as the currently-loaded page as far as I can tell, but any access is too much. The common attacks have nothing to do with cookies so that restriction wouldn't help. They usually set the user's Facebook status to "do this to see who's viewed your profile" with the same description on how to get it to "work", and thus the hack spreads.
In reply to comment 37, I agree that it wouldn't take much more effort to get a user to do Ctrl+Shift+K, Ctrl+V, Enter, Ctrl+Shift+K but it's at least more visually obvious that something is happening.
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.
Pretty trivially, yes. Not sure it's all that useful to have a way to do that, though.
Created attachment 532089 [details] [diff] [review]
Drop the load and pretend nothing happened
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.
(In reply to comment #38)
We are not talking about bookmarklets, those can be vetted before being recorded as bookmarks and allowed without sandboxing.
> are things that interact with the contents of the current page,
> which are precisely the sorts of usecases that cause the problems described
> the current page, so this bug basically describes an XSS vulnerability.
> Personally I would be fine completely disabling both bookmarklets and js
> URLs, most users don't even know what either function is.
Noted, not going to break these, esp. bookmarklets. Everyone is willing to break working and established features for some new and supposedly better way, but we need proof the new way is better before we break the old way, and where we can, we should mitigate without complete breakage.
> and/or bookmarklets could access the *current* page contents (i.e. the DOM),
> but otherwise ran in an incognito context, so that any actions they initiate
> have no access to cookies? Would that prevent the sorts of attacks
> described without disabling too much useful functionality?
This is an interesting area because it’s hard to know what detail of instruction it is possible to trick a user into following. It is also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).
See bug 656433.