Open Bug 527530 (bookmarklet-xss) Opened 15 years ago Updated 2 months ago

[meta] Social Engineering Issue with "javascript:" URLs [read bug #680302 before commenting here]

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect

Tracking

()

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug,
URL
)

Details

(Keywords: meta, sec-other, Whiteboard: [sg:nse meta])

Attachments

(1 obsolete file) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

This vulnerability is with regards to how easy it is to create a XSS + worm + phishing attack without necessarily triggering a non-technical user's security alarm. This could become a common attack vector at any point in time.

1. Create a Facebook group, 'Get $25 from $BANK'. (This works for any social networking site.)
2. Provide simple, easy-to-follow directions that will walk the person through using a "javascript:" URL, causing the user to create their own XSS hole in the social networking web application.
3. Use your new access to help promote the group in a worm-style manner, in a TRUSTED ENVIRONMENT: "Your friend Joe Smith has invited you to join the group, 'Get $25 from $BANK'."

Non-malicious examples of 1-3 in the wild:
-> http://www.facebook.com/group.php?gid=170096529644&v=info
-> javascript:var numfriends=document.getElementById('friends').getElementsByTagName('li').length;fs.click(document.getElementById('friends').getElementsByTagName('a')[1].parentNode);for(var i=0; i < numfriends; i++){fs.click(document.getElementById('friends').getElementsByTagName('a')[i].parentNode);}

4. Add a script loader into the "javascript:" URL. Any will do.
-> http://www.nczonline.net/blog/2009/07/28/the-best-way-to-load-external-javascript/

5. Use the script loader to load http://www.example.com/maliciousscript.js which mutates the DOM (blows everything away)--without making a page request--and turns it into a phishing site.

*** <FIXABLE PROBLEM> ***

6. Note that the URL still displays the "javascript:" URL. This effectively masks the site that the user is presently on (facebook.com, controlled by example.com/maliciousscript.js). With properly written instructions on the Facebook group the user will implicitly believe that they are on the actual $BANK site in spite of the "javascript:" URL being displayed in the location bar, *because they specifically pasted it there to create the action.*

*** </FIXABLE PROBLEM> ***

7. Steal usernames and passwords from thousands of people. Profit.

Reproducible: Always

Steps to Reproduce:
Enter a "javascript:" URL, note that it persists.
Actual Results:  
The "javascript:" URL persists.

Expected Results:  
Possible solution: reset the location bar to the actual site after executing a "javascript:" URL.

I've reported this "non-feature" to Webkit as well, bug 31270.
OS: Mac OS X → All
Hardware: x86 → All
No reason to keep this bug hidden.  Bookmarklets are widely used though perhaps poorly understood from a security perspective.
Group: core-security
The bookmarklets actually scare me less as for some reason they don't persist the JS in the location bar. Manually entered "javascript:" URLs persist and mask the underlying URL.

I hid this as to reduce the likelihood of somebody exploiting this while FB is asleep at the wheel (I did report it to them as well, twice now, regarding two different groups). There are presently about 600k people in the linked group whose popularity is being promoted through the worm approach. Training people that this is safe is a BAD THING (TM).

With regards to security, just being overly cautious.
To clarify, the change I am suggesting:

Immediately after execution of a "javascript:" URL, return the location bar to its prior state.

This would prevent the phishing site from hiding behind the "javascript:" URL.
Full walkthrough of an attack here:
http://nathanhammond.com/social-engineering-issue-with-javascript-urls
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
FYI, I'm probably going to split this bug into multiple, short and longer term fixes.

Short term: disallow pasting of javascript: URLs into the URL bar
Longer term: additionally require that bookmarklets be "whitelisted" in the 
             Bookmark Manager before it can run JavaScript

CCing sicking, who I know has an opinion about how this should work.
FWIW, current intent in Chrome is to do your "short term" fix by stripping "javascript:" from pasted text, but not the "long term" fix of requiring bookmark whitelisting.  Personally I'd really prefer to not mess with bookmarklets unless we see that attackers have successfully shifted to using them to widely exploit people.  I hope the "short term" fix is sufficiently successful on its own.
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 ).
(In reply to comment #7)
> FWIW, current intent in Chrome is to do your "short term" fix by stripping
> "javascript:" from pasted text

Will Chrome also do the same for drag-and-dropped text onto the URL bar?
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.
Depends on: 656433
Depends on: 305692
Whiteboard: [sg:want P1]
The URL bar is a terrible UI for "I want to type a script and execute it against the current page".  It requires a bunch of extra typing, "javascript:" and "void 0". The web console is closer, but it's bulky for my taste, and I'd like persistent history.

Similarly, bookmarklets are terrible UI for "I want to save a script from this page in order to execute it against other pages when I click a button".  Installable user script buttons should be a separate feature from bookmarks.  (See also bug 72374, bug 371179, bug 371923, bug 476505.)
Keywords: meta
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 :(
Depends on: 656823
Depends on: 371179
Depends on: bookmarklet-warning
Depends on: 476505
(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?
Thinking caps, people! We have sandboxes and membranes, pervasive mediation. What is the threat? If it's cookie reading, we can block that. If it is the javascript URL communicating with a server, we can even block that. Only for ones loaded by hand (typed or pasted) into the URL bar, of course.

/be
I think we should set aside scratchpad for now (discuss that in its own bug, maybe bug 656544) and just consider location bar entries (type/paste/drop). I think we should solve that as well, but the location bar is common across all browsers and a very juicy target for social engineering attacks since non-techie users are very comfortable playing with it.

The crux of this social engineering attack as I see it is misuse of a feature: the user is convinced to use the location bar to run a script in the context of the target site.  The attacks I've seen in the wild interact with the content directly and, perhaps, send messages to all your contacts.  It's not stealing cookies or exfiltrating data, it's doing all of the above; both the browser and web site in this case are confused deputies.

The location bar is for locations... perhaps we should treat it that way?  Is the value of allowing javascript: URLs in the location bar worth the potential for abuse?  I'm not convinced it is -- especially since there are plenty of other, more appropriate places for people to write scripts to interact with arbitrary web sites (firebug, scratchpad, web console, etc).
(In reply to comment #19)
> I think we should set aside scratchpad for now (discuss that in its own bug,
> maybe bug 656544) and just consider location bar entries (type/paste/drop).

We need to look around the next corner. Security properties are non-modular, this is not the last place to enter JS run against the page that can be attacked by social engineering.

> I think we should solve that as well, but the location bar is common across
> all browsers and a very juicy target for social engineering attacks since
> non-techie users are very comfortable playing with it.

This is at most an argument for a short-term solution that matches IE9 and Chrome and goes no further.

> The crux of this social engineering attack as I see it is misuse of a
> feature: the user is convinced to use the location bar to run a script in
> the context of the target site.  The attacks I've seen in the wild interact
> with the content directly and, perhaps, send messages to all your contacts. 
> It's not stealing cookies or exfiltrating data, it's doing all of the above;
> both the browser and web site in this case are confused deputies.

Right, but we can pervasively mediate and block all mutations and communication. This still allows inspection with display via either alert, or generation of a new document by the non-undefined result of evaluating the JS URL. This is the valid use-case for javascript: in the URL bar.

> The location bar is for locations... perhaps we should treat it that way? 
> Is the value of allowing javascript: URLs in the location bar worth the
> potential for abuse?  I'm not convinced it is -- especially since there are
> plenty of other, more appropriate places for people to write scripts to
> interact with arbitrary web sites (firebug, scratchpad, web console, etc).

I don't think we are quite going in circles -- I don't want to exaggerate the vulnerability of web console and scratchbox -- but they are probably "about" as attackable.

If these other ways of entering JS can be attacked as well, but they have different interaction designs and economics. We could use readonly-local/no-remote-reads-or-writes sandboxing for them too if they are attacked, with a pref that developers have to flip, or a captcha-style quiz to make sure the user is a developer. Half-kidding.

This is a hard problem but turning things off one by one seems worse than taking advantage of our membrane/sandbox infrastructure.

If we don't try, we won't know what to do next time, and turning off the other ways for the user to type JS in and evaluate it against the current page will hit developers hard.

Maybe the social-engineering attacks won't go after the developer UIs. I hope not. But we're better off defending than disabling, starting with the URL bar. Otherwise we are in a progressively weaker position.

/be
(In reply to comment #20)
> Right, but we can pervasively mediate and block all mutations and
> communication. This still allows inspection with display via either alert,
> or generation of a new document by the non-undefined result of evaluating
> the JS URL. This is the valid use-case for javascript: in the URL bar.

The generated document would have to be sandboxed, and so on for documents it might generate.

I'm suggesting this bug be morphed into a Core bug in some component.

/be
(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
(In reply to comment #20)
> We need to look around the next corner. Security properties are non-modular,
> this is not the last place to enter JS run against the page that can be
> attacked by social engineering.

Yeah, I'm an idiot.  I just re-read the subject line and had misread the scope as limited to location bar URLs.  :P 

> Right, but we can pervasively mediate and block all mutations and
> communication. This still allows inspection with display via either alert,
> or generation of a new document by the non-undefined result of evaluating
> the JS URL. This is the valid use-case for javascript: in the URL bar.

I see now.  We would want to block all interactions with the content (including clicks, function calls, etc) except for read and create-new-document operations.  I agree this is a good direction, probably something that can include bookmarklets.  There's something to be said about user scripts that can modify a page on the fly, though perhaps these are better served as add-ons.
  
> [snip]
> This is a hard problem but turning things off one by one seems worse than
> taking advantage of our membrane/sandbox infrastructure.

I agree here, but I still keep coming back to wondering specifically whether the URL bar is the right place for javascript: at all.  Can we do both?  Defend other entry points with membrane/sandbox but also take a harder line on the URL bar that I would argue is not the right place for user scripts?

> If we don't try, we won't know what to do next time, and turning off the
> other ways for the user to type JS in and evaluate it against the current
> page will hit developers hard.

Insert more agreement from me.  I am not at all in favor of disabling the web console or other ways to type in and evaluate JS.  Those features are *intended* for that use, whereas I don't agree this is the case with the location bar.
> I see now.  We would want to block all interactions with the content
> (including clicks, function calls, etc) except for read and
> create-new-document operations.  I agree this is a good direction, probably
> something that can include bookmarklets.  There's something to be said about
> user scripts that can modify a page on the fly, though perhaps these are
> better served as add-ons.   

FYI, Rails applications put the CSRF token in a <meta> tag in the document, and I'm sure some other sites put security tokens in the DOM, relying on the fact that you can't read the answer of a cross-site XHR. So javascript: and its kin should not get read access to the current page.

I like the idea of forcing bookmarklets such as Readability to be add-ons  because installing add-ons looks like downloading software, so users are already trained to be careful about it.

> If we don't try, we won't know what to do next time, and turning off the
> other ways for the user to type JS in and evaluate it against the current
> page will hit developers hard.

I think the address bar deserves special consideration because (1) it is not intuitive that you can impact the current page by typing something in the address bar, (2) it's causing a lot of damage right now, to many real people*, (3) I can tell people "if you don't want to get hacked, don't open any development console, here's what they look like", but I can't tell them "don't put anything in the address bar". If regular people have to understand javascript: vs http: / https:, they'll hate us even more.

This will not fix all the attacks, but it will put people in a better position to defend themselves. And it buys time for the more comprehensive approach discussed here and in bug 493857.

Thank you.
Depends on: 658383
Whiteboard: [sg:want P1] → [sg:nse meta]
I've put my thinking cap on and come up with this, which should solve *all* javascript: (and data: etc.) copy/paste/run security problems.

For the address bar:

1) The 1st time a user enters a javascript: URI, put up the following warning:

WARNING! You are about to do something that can destroy your web accounts and send viruses to all your friends. Type 'I Accept Risk' to continue:

_____________________

[I Accept Risk] [Cancel]

2) The 2nd time a user enters a javascript URI *within* *1* *month*, put up the same warning but remove the text entry box and associated text and add a checkbox above the buttons with the label 'Always accept risk'.

For Scratchpad and Web Console, etc. do the same thing (i.e. if the user has never typed any commands into those consoles before, do the 1st and 2nd warnings).

My guess is this will prevent >95% of cases, which (like vaccinating against a real biological virus) should be enough to render the virus ineffective. There's also no need to mess with complicated concepts like sandboxes.

For the paranoid, reset the checkbox setting every time a year has elapsed since the user last typed javascript:. Can be combined with Sync for extra convenience.
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.
Depends on: 664552
Depends on: 674161
Breaking long-standing functionality is not the best approach to tightening security. The ability to run javascript:* from the address bar has legitimate uses that people count on.

I distribute a javascript library.  Folks are encouraged to run "javascript:fb.key()" from the address bar after installation.  This function presents an alert dialog that gives information about the installed version and its configuration.  It is used to confirm that the library is installed and configured correctly and is functional and available.  Now with Firefox 6 some of my users are under the impression that the library is broken on their sites.  The documentation and support information has always encouraged this configuration check which works reliably and dependably from every active version of every browser except Firefox 6.  This can't be considered a good thing.
Removing obsolete features reduces attack surface, and simplifies the mental model that us software developers have to deal with, so it is a very legitimate way of increasing security, asides from good software engineering practice.

Your javascript library's users are JS programmers, right? I would assume they either know or are willing to learn how to use their browser's built-in debugger console. Firefox 5+ has the Web Console, and Firebug works for older Firefox versions. Chrome and safari have the Developer Tools, and I'm sure IE and Opera have similar features. These are vastly superior to the javascript: address bar hack.
You can also re-enable this easily using about:config.
(In reply to Victor Costan from comment #30)
@Victor,
This really is an odd response in a number of different ways.  I should probably refrain from responding to it, but I can't help msyelf.  :-)

Obsolete feature? Who decided it's obsolete?  I guess we could say it's obsolete because its been removed from FF6 but this would be begging the question. Sure, removing features reduces attack surface.  The system that takes no input and provides no output is the most secure system of all. The point is, javascript: functionality does not have to be removed to address the security concerns raised in this thread. We're killing the patient to cure the disease.  And agreed again, reduced functionality reduces the "mental model" that developers have to deal with, but this is hardly a legitimate driver for breaking existing software functionality.  The are other good software engineering practices that come into play as well.  How about, developer convenience does not trump user requirements or product functionality, for one?

No, my library's users are not all programmers.  There's a whole range of the very technically savvy through to WordPress users who have never touched a line of HTML or script in their lives.  But my library's audience is completely irrelevant to the discussion of whether it was a good idea to break this functionality in Firefox.  And I gather you are suggesting that we document something like "In IE version 8 or later, press F12 to get the developer console, select 'script', select 'console', in the bottom right corner type...   In Opera select 'tools/advanced/Dragonfly', click the little button that looks like '>_',...".  Well, you get the idea.  This must be what you are referring to as being "vastly superior" to using javacript: in the address bar.  You would think that the vastness of the superiority would make it blatantly obvious to me, but it actually evades me completely.
"Adress bar hack"?  What does this mean to call that functionality a hack?  It's been a standard and useful capability of all browsers since the turn of the century (afaik).  I think the impulse to now label it a hack is to somehow back-justify the decision to kill it.

Look, I'm just presenting some info here and a suggestion.  The info is that there are people who rely on the javascript: capability and it is used on a near daily basis.  It's a big world and I would be very surprised if I and my library users are the only ones who take advantage of it.  It's a capability that is documented in many places and the expectation is that it works everywhere.  It currently works everywhere except FF6. Perhaps the devs were not aware that people actually use this.

We need secure browsers and we need new browser versions to help protect against new exploits.  It was a mistake to completely remove the javascript: functionality because sufficient protection against the exploit can be implemented without the drastic action of removing the functionality altogether.  The Chrome approach of stripping "javascript:" out of pasted text and reverting the address bar back to show the page URI after execution is a good one and is sufficient.

I'm advocating that the FF team recognize that they killed functionality that people legitimately use and rely on, that this wasn't a good idea because it was not necessary to cover the exploit, and that they re-implement the functionality (that is, leave it on by default) and implement the Chrome mitigation strategy, or similar, in the next release.

Cheers...
Sorry if I missed it: where is the rationale for Firefox doing more (in the restrictive or breaking change to which Byron objects) than IE9 and Chrome to deal with social-engineering of javascript: URL copy/paste?

/be
(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?
Please note that this was not a theoretical attack. We didn't disable this because we were worried that people might get attacked.

We disabled this because there were widespread worms on some sites, in particular facebook, where users were asked to copy-paste javascript URLs into their url bar and once they did it would send the same message to all the users friends.

Simply saying that it's users fault is not a workable solution.

Additionally, we have a much better UI for executing snippets of javascript, it's called the developer console.

I can sympathize with that many people will have to relearn and use this new UI. I'm one of those people. It's a pain and I still start typing in the wrong place all the time.

But I have even more sympathy for the people that get hacked on facebook because they didn't know that copy-pasting something in the address bar could compromise their facebook account.
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.
@Byron

I think javascript: should have never been allowed in the address bar, because it violates the principle of least surprise. As a user, when I type something in the address bar, I expect that to take me to some Web site. After all, it's called an address bar. I would not expect it to issue a command to the page that I'm on right now. As a user, when someone sends me a link, I expect to be able to click it and check it out, and I don't want to have to think and understand the link.

For your use case, I think that the Web console is superior because, once it is popped up, it can show any errors that might have prevented your library from working.

Also, I don't think you need to document bringing up a Web console in all the browsers. I would tell users "if you know how to bring up a web console, evaluate fb in it; if not, here are steps-by-steps instructions on how to do it in Firefox" (where step 1 is a firefox download URL) This way you only have to give detailed instructions for one browser.

Last, advanced functionality that can harm untrained users _should_ be disabled by default, so that users are encouraged to try new things.
(In reply to Johnathan Nightingale [:johnath] from comment #37)
> (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. 

If you are going to continue removing features which can be shown to be abusable through social engineering (which is all of them probably), then you are.

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

Where are the insults?  That there are clueless users?  That's an undeniable fact.  The insult is Mozilla treating everyone like a clueless user, when it's so easy to accommodate both camps (those able and willing to take responsibility for javascript: URIs and those not).  Speaking of which, you did not answer, why can't there be an pref for this?
> Where are the insults?  That there are clueless users?  That's an undeniable
> fact.  The insult is Mozilla treating everyone like a clueless user, when
> it's so easy to accommodate both camps (those able and willing to take
> responsibility for javascript: URIs and those not).  Speaking of which, you
> did not answer, why can't there be an pref for this?

1) I think you could've gotten the answer by yourself by now. I opened about:config and started typing "javascript" in the search bar. "browser.urlbar.filter.javascript" seems pretty obvious to me.

2) It takes 13+N keystrokes to eval an N-character string using the "javascript:" pseudo-protocol (Ctrl+L, "javascript:", N characters, Enter). The Web Console requires 4+N keystrokes (Ctrl+Shift+K, N characters, Enter). So it's nicer for expert developers. It's also easier to discover for new developers.

I can't see why you're advocating "javascript:", asides from the issue of having to learn something new.
(In reply to Victor Costan from comment #40)
> > Where are the insults?  That there are clueless users?  That's an undeniable
> > fact.  The insult is Mozilla treating everyone like a clueless user, when
> > it's so easy to accommodate both camps (those able and willing to take
> > responsibility for javascript: URIs and those not).  Speaking of which, you
> > did not answer, why can't there be an pref for this?
> 
> 1) I think you could've gotten the answer by yourself by now. I opened
> about:config and started typing "javascript" in the search bar.
> "browser.urlbar.filter.javascript" seems pretty obvious to me.

Well aren't you a showoff, now go the rest of the way and figure out what that pref actually does.
(In reply to al_9x from comment #41)
> > 1) I think you could've gotten the answer by yourself by now. I opened
> > about:config and started typing "javascript" in the search bar.
> > "browser.urlbar.filter.javascript" seems pretty obvious to me.
> 
> Well aren't you a showoff, now go the rest of the way and figure out what
> that pref actually does.

Bummer. File a bug?
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
Jonas, comment 35 does not say why we didn't prevent pasting only. Intentionally typing javascript: is allowed by IE9 and Chrome. What was the exact rationale for going beyond restricting just paste, which was the exploit vector in the social engineering attack?

/be
Bug 680302 - a pref to control the javascript: urlbar restriction (for typed and/or pasted URIs), introduced by Bug 656433
I originally reported this bug (almost two years ago!) during the very first wave of these attacks. A bit about me:

1. I'm a web developer who has had a site where there were attempts to be exploited in this manner. Preventing this sort of thing is possible, but not easy. My partial solution was a modified YUI Compressor which would output randomized function names, form element IDs, form.elements.length and more for things which could change application state. It didn't protect against info/cookie theft, but prevented simple propagation. Paired with monitoring of site interactions for abnormal behavior we were able to stop most things in their tracks. However, this was incredibly annoying and seriously reduced the performance of both the servers and the site.
2. Like most of you, I'm tech support for friends and family who don't know what they're doing in front of a computer. Every other week I have to help somebody who had an account hijacked or caught a virus.
3. I'm a developer who (out of an old and well-trained habit) often uses the location bar as a quick and dirty way to snag information off a page.

In spite of my own legitimate use-case (described in 3) I feel strongly that we need to err in favor of protecting the majority end-user of the browser. And I posit to all of you that by doing so we are also protecting our own: fewer hijacked accounts mean less work helping our friends and in developing ludicrous tools to reduce the impact of self-XSS. And if you ever had to do what I described in point number 1 above you would most assuredly share my opinion.

That being said, there are three possible ways I'm aware of to enter a javascript: URL into the location bar: typing, pasting, and dropping. Of those, two are especially exploitable in social engineering attacks, dropping and pasting. Typing a javascript: URL is *not* a particularly exploitable method as the verbosity of any malicious script will be enough of a barrier to entry. Pair that with case-sensitivity and people's unfamiliarity with JS and there is almost no way that somebody effectively self-XSS's by typing in the location bar.

I'm completely happy with removing two of the three vectors for entry and I applaud the decision made to push those changes in FF6. I'm with Brendan (Comment #44) as to discovering where and why the decision was made to remove typing as I'm a little less happy with losing that ability. But let it be known that it is something that I'm willing to sacrifice and retrain my brain/fingers for. :) 
(Can we track copy behavior from within Firefox? As in allowing certain interactions so long as the text didn't come from within the browser?)

In any case, we will *never* fully solve this issue so long as there is an available interface for running JavaScript in the context of the current page. As to whether that is a good idea, who knows. Heck, I bet most *developers* don't think about the fact that by inserting others' scripts into their page they're relinquishing full control to their site ... and heaven forbid the script-provider get hacked!

As a technical solution maybe we enforce Caja Compliance or something like that? I am honestly amused by the "reverse social engineering" approach mentioned in Comment #27, "Do you really want to look like an idiot in front of your friends?" I feel like that might be the most effective approach we can come up with. Being a social problem to begin with, a social solution is most likely to be the correct solution.
I agree with Byron - I think that, although the decision to effectively stop javascript in the address bar in FF6 has been made with all good intentions, there has been little thought towards the many genuine developers who use this controversial feature.

For example: I distribute javascript snippets, used to get information from pages and for UI manipulation, which most users copy and paste into the address bar to run. Many are not developers, thus won't know how to use tools like the console. I also (despite knowing that there are, perhaps better tools for doing this) frequently use javascript in the url bar to debug pages (as I suspect many other developers do) due to the speed and simplicity of it.

I do appreciate the need to protect the majority of users and I agree with Victor in that, javascript: should have never been allowed in the first place, but it is too late to argue that now.

I believe that more information would allow for a better informed and more agreeable, long solution to the problem. Is there any empirical data out there regarding the use of javascript in the address bar? Eg: how many people are XSSing themselves, where are attacks aimed at, how many people are using "javascript:" for genuine purposes?

I personally suspect that 95% of attacks are happening on social networking sites. If that is the case, could the problem be solved in the short term by just stopping "javascript:" on Facebook, opposed to removing functionality, with little thought aside from that of security.
(In reply to Brendan Eich [:brendan] from comment #44)
> Jonas, comment 35 does not say why we didn't prevent pasting only.
> Intentionally typing javascript: is allowed by IE9 and Chrome. What was the
> exact rationale for going beyond restricting just paste, which was the
> exploit vector in the social engineering attack?
> 
> /be

This was asked two weeks ago, still no answer.
(In reply to Jesse Ruderman from comment #49)
> It was answered the first time Brendan asked it:

The answer seems to be that a hypothetical user can (theoretically) be talked into typing in the javascript: url.

But that argument is more reductio ad absurdum than a justification.  There is no theoretical limit to what such a hypothetical naive user can be talked into.  What about opening the web console or the error console and pasting in code there.  That's probably easier than a combination of pasting and typing on the urlbar.  Are you going to remove the consoles?
The address bar has a long history, in most users' minds, as being a way to navigate, not a way to modify their browser.
I hate to add fuel to the flames here, but FWIW, as someone involved in making the decisions about Chrome's address bar, we really felt the likelihood of an attacker convincing the user to manually type "javascript:" and then paste the relevant attack code was so much lower than in the classic "just paste this whole string" that the benefit to developers of still being able to type that outweighed any security gain.  We could be wrong, and if we see attackers successfully using an attack like this we won't hesitate to lock down further, but at least for now the Chrome Security + UI decision is "allowing typing of 'javascript:' is a net win."
(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
This is rediculous, removing such a used feature without giving the option to re-enable it. I use this on a daily basis for many legitimate purposes.
Sure it might be a risk if the user is uninformed, but that's no excuse for not putting an option to reenable it... Maybe even with a there be dragons message.

Limiting many developers who are already very informed about the risks is not going to increase acceptance of FireFox 6.

If anyone can link me to a FireFox 5 download on the mozilla servers I'd appreciate it. I need this feature, whether it requires using an older brower or using a different browser all together. It may be time to test Chrome if this isn't rectified. My site members will most likely also follow me in whatever decision I make.

I'm disappointed in the lacking of fore thought.

Give the user the power, even if it means educating them before they enable it with a warning.

An alert box: JavaScripts & Bookmarklets in the address bar may be able to steal account information, perform automated dangerous tasks, etc. Do you trust the author and wish to take these risks? [Yes] [No] [Always] [Always for this site]
(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
I'm happy to see this thread come back to life as it was previously left unresolved with no going-forward decisions being made.  People are passionate about their browsers and the discussion is easily side-tracked into largely irrelevant opinion pieces about how other people should use their browsers.

To reiterate and focus: It was not necessary to disable typed javascript in the address bar.  Stripping pasted javascript is sufficient exploit mitigation.  In this respect, removing typed javascript was a mistake.

I agree that the question of how and where the decision was taken to go beyond other browsers and remove typed js in addition to pasted js has not been answered.  But it doesn't matter that much.  What matters is the forward-looking policy decisions and action plans.

Can the Firefox design and dev crew please agree that *typed* javascript should be re-enabled and then work quickly to put this back in the next release.

Thanks for listening...
Doing what IE and Chrome have done would essentially reopen the security hole, and we should not do that.

Successful worms indicate that the percentage of users who become victims is much higher than our threshold for "blaming the user". I don't see any reason to believe that adding two keystrokes (Home, J) to the attack instructions would have much effect on the success rate.  There would still be nothing indicating to users that they are doing something other than navigating to a secret web page.

We have numerous UIs for executing scripts. Built in we have bookmarklets, Scratchpad, the Web Console, GCLI, and the Error Console. Extensions include Greasemonkey, Scriptish, the Javascript Executer Toolbar, Execute JS, and xqjs.

Most of them can be activated with fewer keystrokes than typing "javascript:". Many of them have additional time-saving features such as method auto-complete, history, sane ways to display output, and not navigating away if you forget to end your script with an expression that evaluates to |undefined|.

Some of them are confusing (see bug 664589), but none are actively misleading like the address bar.  If they don't meet your use cases, we should figure out why and fix that.
What are the use-cases for allowing typed-but-not pasted javascript?

Disallowing pastes seems quite reasonable to me (previously linked stuff from others, and the fact that other browsers have decided to block it). I think we're pretty unlikely to change that.

Allowing typed-but-not-pasted is an interesting variation, but it's not clear to me what this is useful for, beyond a few trivial examples and things already well-supported by our current nascent devtools. There's a saying that Programmers are Lazy by Virtue, which tends to self-limit the usefulness or repeatedly typing in javascript: URIs into the location bar (given more efficient alternatives).
@Jesse
Your claim the re-enabling typed javascript re-opens the security hole is counter-factual.  The exploit is a copy-and-paste exploit.  It is highly unlikely that it would have been successful if the instructions invited people to type "javascript:..." in their address bars.  Most people would be too lazy or too suspicious to follow such instructions and most people would pause to wonder why they would want to do this.  The necessity to type "javascript" also alerts people that they are running code.  I'm not sure what you're getting at about "Home J", but typing that doesn't get anybody anywhere.  The exploit isn't going to be in auto-complete until after it has been fully entered and executed, and  javascript commands probably shouldn't be remembered by auto-complete anyway.

Your mention of the numerous other ways that javascript can be executed from the browser presents a solid illustration of why typed javascript in the address bar should not be disabled.  If it were the case that it was necessary to disable typed javascript to prevent the exploit then it would be equally necessary to prevent the execution of javascript in each of the other listed contexts as well, for exactly the same reason.  If a social-engineering exploit of "type javascript:foobar() <enter> into the address bar" will work, then so will the exploit "type ctrl-shift-k foobar() <enter>".  Thus, it is false that allowing typed javascript in the address bar re-opens a security hole.

@Justin
You ask what are the use cases for typed javascript in the address bar.  You're asking the wrong question.  This would be the right question for adding new functionality, but in this case we are talking about the removal of ubiquitous and long-standing functionality that many people use.  The right question for such a removal is to ask what the justification for removal is.  I would suggest that security is the only valid reason to strip (defacto) standard and widely used functionality, and we have already established that removal of typed javascript is not required from a security perspective.  Asking for use-cases for something that people have been using in all browsers for 10 years is a distraction from the issue at hand.  That issue is that typed javascript was removed specifically in response to an active social-engineering exploit when it was only pasted javascript that needed to be removed.

But, at the risk of fueling the distraction, I'll give you my use-case.  (This is a repeat.)  I provide a function in my js library that users can execute to check the configuration and install status of the library.  As part of support and trouble-shooting, people are asked to execute this function to gather information about their installation.  If you are wondering why we don't direct them to a developer panel to execute this function, that's simple: Scratchpad, etc. are browser specific and work only for folks using Firefox.  We would need a different set of reasonably complex instructions for each browser that an end-user might choose to use.  For now, we will say "from any browser except Firefox...".  (By the way, I would place very good odds on a bet that no other major browser will be disabling typed javascript in the address bar.)

But I can't emphasize enough that it is not up to us lowly end-users to justify our use of this capability through use cases.  The justification needed to be for the design and dev teams' removal of this capability, and that removal was in fact an unjustified overreach in response to a paste exploit.

Who makes go/no-go decisions?  Can we get to a decision point on re-instating typed javascript in V7 and/or V8?
No capability was removed. You can re-enable this feature by setting browser.urlbar.filter.javascript to false in about:config.

The vast majority of end users don't care about this feature and its a risk for them. 

Developers and power users can switch this back on via about:config. Lets end the discussion here. This is really not going anywhere.
Summary: Social Engineering Issue with "javascript:" URLs → Social Engineering Issue with "javascript:" URLs [read comment #60 before replying]
@Andreas
Sorry, I understand that you might not want a response but many of your statements are false.

Perhaps the capability was not strictly removed, but it was certainly disabled.  Up until FF6 people were running javascript:* from the address bar.  When they upgraded to FF6 that stopped working.  Use whatever language you want, that's removal of a capability that people use.  Do you really mean to suggest that we tell our users "if you're using FF, enter about:config in the address bar, ignore the void warranty warning, find...".

"The vast majority of end users don't care about this feature..." - true.
"...and its a risk for them." - false.

I'm 100% in agreement about hoping the discussion will stop.  I think everything has been said that needs to be said.  This is why I keep asking who makes go/no-go decisions and can we get one made on this topic.

Thanks...
(In reply to Andreas Gal :gal from comment #60)
> No capability was removed. You can re-enable this feature by setting
> browser.urlbar.filter.javascript to false in about:config.
> 
> The vast majority of end users don't care about this feature and its a risk
> for them. 
> 
> Developers and power users can switch this back on via about:config. Lets
> end the discussion here. This is really not going anywhere.

That's twice now you've made this false claim, this time with more aplomb.  Check you facts and stop embarrassing yourself.  A pref to re-enable does not exist, Bug 680302 is for creating it.  filter.javascript filters js urls from the urlbar dropdown (Bug 417798)
(In reply to al_9x from comment #62)
> That's twice now you've made this false claim, this time with more aplomb. 
> Check you facts and stop embarrassing yourself.  A pref to re-enable does
> not exist, Bug 680302 is for creating it.  filter.javascript filters js urls
> from the urlbar dropdown (Bug 417798)

I think I was the one who ticked you off last time. In either case, you could be nicer in your response. You have to agree that the preference name is misleading.

@Byron I disagree with your assertion that existing features are exempt from the requirement of use cases. By eliminating features that don't solve current use cases, the UI and the codebase can be less complicated. This makes the software easier to use and easier to develop.

The "Home J" issue (took me a while to figure it out) means that the attackers can ask the user to copy-paste "avascript:bad-stuff-here", then press Home to move the cursor at the beginning of the bar, and press J to complete the location to "javascript".
(In reply to Victor Costan from comment #63)
> (In reply to al_9x from comment #62)
> > That's twice now you've made this false claim, this time with more aplomb. 
> > Check you facts and stop embarrassing yourself.  A pref to re-enable does
> > not exist, Bug 680302 is for creating it.  filter.javascript filters js urls
> > from the urlbar dropdown (Bug 417798)
> 
> I think I was the one who ticked you off last time. In either case, you
> could be nicer in your response. You have to agree that the preference name
> is misleading.
> 

No, I did not have you in mind. Andreas Gal, who is a mozilla dev, twice claimed that this functionality can be reenabled (Comment 31, Comment 60)  The first time I asked him to clarify (Comment 34), but he did not bother to verify anything and now just repeated the same false claim, even though it was already indicated by me and acknowledged by you that the pref he had in mind does not apply here.

He wants the discussion to end based on his nonsense and changed the title of this bug to direct people to his misleading comment.  Perhaps you can ask him to be nicer and not bs us.
Summary: Social Engineering Issue with "javascript:" URLs [read comment #60 before replying] → Social Engineering Issue with "javascript:" URLs [read bug #680302 before commenting here]
I think we (Mozilla module owners involved here) just painted a "Kick Me" sign and hung it on our own backs. It doesn't matter how much someone abhors the URL bar being used by folks who have for years (15+, possibly) typed javascript: to good effect. That's what some of our users have become accustomed to typing, and we broke them -- and our competition did not. We broke them with zero evidence of social-engineered attacks exploiting typing rather than pasting.

The kick-me signs we get hung on us by others, we can deal with -- take the kicks, turn and fight, whatever. I'm writing here because we can't afford to screw around with our own signs. Differentiating against other leading browsers here does not win us users, it simply risks losing users. I think it's time to reverse a bad decision. It's not the biggest or the baddest, but so what? We correct course (I mean fix bugs, including regressions, even intended ones) all the time.

/be
I stand corrected, the pref mentioned above is no longer sufficient to restore the previous behavior. I grabbed bug 680302 to add a way re-enable javascript execution from the url bar. A pref might not be the best and final solution, but its a first minimal fix we definitely must have. I will land it as soon as I can get review from the frontend team.
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.)
Chrome upgrades so well that Chrome 12 is a really small sample (about 2% of Chrome 13/14 generally), thus I think that 151% was just noise -- similar for Firefox 4/5's seeming improvement over Firefox 3.

I believe this sample was mostly this "type j then paste" scam, but I'll double check.

I'm worried about the end state as well. We really don't know if requiring typing 'javascript' ala IE9 is enough. I don't think any of this should be a single keystroke away for non-developers who don't realize the implications, but I also sympathize completely with the pain of getting there (or somewhere else -- e.g., Brendan's sandboxing point).
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 ;-)
Whatever we do, we are just going to be forcing them to find new ways of tricking the victims.

The best answer is education... Keep the address bar, but give them a warning notice when they try to paste JS in there with a continue or cancel option, and the never show this message again tick box, or don't show for another week tick box.

=================
Security Warning!
=================
Pasting javascript in this box may give other users access to your account, other personal data and some ability to manipulate/control your computer. Only accept continue if you are sure you can trust this code.
=================
[x] Don't show this warning for another week.
[Continue] [Cancel]
=================

Also, start looking at the source of the virus, in the example above we have someone among other things trying to convince the user to click an affiliate link... hxxp://partners.optimalfusion.com/z/5507/CD2871/
Report this to the affiliate company and have their account banned.

If we keep locking everything down eventually the browsers will become unusable.

Then again maybe that's something that should be looked into, 2 strains of FireFox, 1 with all exploitable elements locked down and no consoles, and another developers version with everything enabled. or just "firefox.exe -developer=on" (I'd still much prefer some education - "Here be dragons!" was always a nice touch)

about:config
Hi all! I'd like to describe some problems I encountered after this "fix" was applied. Maybe someone will show me possible workarounds, solutions for at least some of them...
First of all - I'm a big fan of bookmarklets, I created probably hundreds of them and solved a few problems of other Fx users (and not only) without a need to install any bulky extensions, Greasemonkey scripts, etc. But now creating bookmarklets in Firefox is a bit harder.
1. Code of bookmarklets stored in Fx is escaped/URL encoded - earlier I could just copy bookmarklet from library, paste it into urlbar, edit and it worked fine. Now, I have to first unescape bookmarklet's code - what is not always easy, especially when there were used both ' (apostrophe) and " (quote) characters and only after that I can continue "crafting" in Scratchpad or Web console.
2. So now, if I plan to reuse code of bookmarklets created earlier, I have to save them also as a file(s) and what is more - remember to copy it/them whenever I'm going to work on other profile, OS, computer, etc. That's quite inconvenient in comparison to syncing bookmarks.
3. Due to "Security error" in Web console and Scratchpad I can't use document.write(); document.open(); document.close() commands - which are faster and more universal than DOM manipulations. I often use document.write() to create (copy) simple forms based on forms in some sites which only work with POST method - and it enables me to simply create bookmark(let) with search keyword for such forms (using POST method).
4. Undo behavior seemed to work better in address bar then history in web console - but now I'm not sure for 100% about that.
5. Also Extensions Developer addon with Javascript Shell is now less helpful than it was before, but that's not related with this bug.

In other words - because of this change creating bookmarklets in Fx is not so pleasant and enjoyable as it was and takes more time. And that's the biggest reason I'm still using 3.6.* version of Fx. The only useful enhancement for me are maybe suggestions in Web console. 

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.
(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.
Depends on: 699893
No longer depends on: 699893
Blocks: 703378
No longer blocks: 703378
Depends on: 703378
Blocks: self-xss
See Also: → 1725626
Summary: Social Engineering Issue with "javascript:" URLs [read bug #680302 before commenting here] → [meta] Social Engineering Issue with "javascript:" URLs [read bug #680302 before commenting here]

The bug assignee didn't login in Bugzilla in the last 7 months.
:sgalich, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: brandon → nobody
Flags: needinfo?(sgalich)
Flags: needinfo?(sgalich)
Alias: bookmarklet-xss
Severity: normal → S3
Attachment #9383690 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: