204779 - view-source: can execute javascript

Status: RESOLVED FIXED

(Core Graveyard :: View Source, defect)

Description

[Zarco Zwier]

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

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

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

Comment 4

[georgi - hopefully not receiving bugspam]

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?

Comment 5

[Zarco Zwier]

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?

Comment 6

[georgi - hopefully not receiving bugspam]

Sure, it better be disabled.

Comment 7

[chris hofmann]

clearing security-sensitive marker

Comment 8

[Zarco Zwier]

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.

Comment 9

[Hidehiro Kozawa]

We can see queer popup when we type url below.

view-source:javascript:location.href="http://www.yahoo.com/";

Comment 10

[Darin Fisher]

Attachment: v1 patch - somewhat of a hack

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

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

> 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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 16

[Darin Fisher]

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 17

[timeless]

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.

Comment 18

[Zarco Zwier]

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

Comment 19

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME

Comment 20

[Daniel Veditz [:dveditz]]

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

Comment 21

[Jason Bassford]

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.

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 23

[Jason Bassford]

Cheers!