User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b; MultiZilla v1.4.0.4A) Gecko/20030505 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b; MultiZilla v1.4.0.4A) Gecko/20030505 When the url above is entered in mozilla, the JavaScript code is executed. Reproducible: Always Steps to Reproduce: Enter url Actual Results: Execute javascript Expected Results: Do nothing

This seems to work for me in 2003050714. Could you please try a newer build (1.4beta is probably going to be released in the next hour or two), or you can try a nightly build from http://ftp.mozilla.org/pub/mozilla/nightly/latest/.

The JS is executed on my Mozilla (build from last week), RedHat 8.0, although I do not see alert (Error: uncaught exception: Permission denied to call method Window.alert). But the point is we should not be running the script at all I think.

This is a little scary. view-source should not run any scripts.

I am not sure this is very scary. After all, the js does not execute as system principal as far as i could test. Is there an exploit with this? The expected result of javascript:alert("test") is to show dialog, so what's the problem with view-source in this case?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030511 still executes JavaScript after view-source: I think the view-source function should only show the source of an (X/XHT/HT)ML URL, not execute JavaScript. Isn't this easily fixed by adding a URL check within the view-source code?

Sure, it better be disabled.

clearing security-sensitive marker

Now using FireFox (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040521 Firefox/0.8.0+) the bug is still present.

We can see queer popup when we type url below. view-source:javascript:location.href="http://www.yahoo.com/";

this patch is somewhat of a hack since it just adds an explicit test for view-source:javascript: down in necko and blocks it. it's probably wrong for necko to know anything about javascript: URIs. we could also invent a new bit for nsIProtocolHandler::protocolFlags that would indicate that the source of a protocol cannot be viewed. hmm...

I don't really like this... how about we use bug 229168's new flag and check for it here, and make javascript:'s protocol handler set that flag? hmm... bz didn't like applying this flag to javascript...

That flag is wrong for javascript:, since the javascript: protocol _can_ result in data to be loaded as a document. Furthermore, that document WILL have source that someone may well want to view. Ideally we'd be using wyciwyg URIs for such documents and hence would be doing view-source on a wyciwyg URI, not on a javascript: URI.... but that's a longstanding issue.

> Furthermore, that document WILL have source that someone may well want to view. Yeah, but ideally w/o re-executing the JS... >Ideally we'd be using wyciwyg URIs for such documents and hence would be doing >view-source on a wyciwyg URI, not on a javascript: URI that sounds like it's a bit nontrivial to do

> that sounds like it's a bit nontrivial to do Yes, but we need it anyway for "reload" to work right on script-generated pages...

So with this patch, I can also no longer view source of something like javascript:"foo" or any other javascript url w/o side-effects...

right, that's probably reason not to take this patch. if a JS URL generates content, we should probably redirect the load to a wyciwyg URL as bz suggests.

Comment on attachment 155059 [details] [diff] [review] v1 patch - somewhat of a hack this is wrong, the bug as summarized should be wontfixed. however as noted in comments changing urls to wyciwyg would be ok.

According to [url=http://www.mozilla.org/security/announce/mfsa2005-43.html]this advisory[/url] the problem has been fixed. Strangely 2 years later it has become a security related problem. Closing this bug

No specific bug / patch referenced as the fix. -> WORKSFORME

No, this was fixed. Bug 290982 listed as blocked here and fixed in the advisory linked from comment 18

The point isn't that it WAS fixed, the point is - what was it fixed by? Can you point to the patch that was checked in or the bug that fixed this? None of the referenced bugs are accessible to me so it's impossible for me to discover which one of those might have done it.

attachment 183234 [details] [diff] [review] of bug 290982 fixed it.

Cheers!