Sanitized suspicious request for MDC page

[orangesoda]

Hi, I just saw this while trying to load a page on MDC:

[NoScript InjectionChecker] JavaScript Injection in ///en/XPCOM_Interface_Reference/nsIPromptService#alert()
(function anonymous() {alert();DUMMY_EXPR;})
----------
[NoScript XSS] Sanitized suspicious request. Original URL [https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIPromptService#alert()] requested from [chrome://browser/content/browser.xul]. Sanitized URL: [https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIPromptService#9449051248036323908].

The page was https://developer.mozilla.org/en/XPCOM_ ... ice#alert()

I'm not sure, but this seems like maybe a false positive. FWIW.

[Tom T.]

Unable to reproduce on Firefox 12.0, and for the sake of testing non-HTML5, nor on Fx 3.6.28.

Since you're using a highly-experimental build, could you please see if it occurs on stable release F12?
If it does not, there may be an issue to bring to the Moz dev team, thanks.

[orangesoda]

I just checked Fx12 and saw it there too. Both my initial report and with Fx12 were with older NoScript versions, so I upgraded to the latest NoScript and I still see it.

STR:

1 - Go to that MDC page
2 - click alert() in the TOC sidebar so you point to the URL fragment that ends with #alert()
3 - reload with that as the URL
4 - I see the redirect and warning from NoScript then.

[therube]

Confirmed on 2.4.2rc6.

Code: Select all

[NoScript XSS] Sanitized suspicious request. Original URL [https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIPromptService#alert()] requested from [chrome://navigator/content/navigator.xul]. Sanitized URL: [https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIPromptService#8915678128585843790].


[Tom T.]

I just checked Fx12 and saw it there too. Both my initial report and with Fx12 were with older NoScript versions, so I upgraded to the latest NoScript and I still see it.

STR:

1 - Go to that MDC page
2 - click alert() in the TOC sidebar so you point to the URL fragment that ends with #alert()
3 - reload with that as the URL
4 - I see the redirect and warning from NoScript then.

I don't seem to find any reference to clicking on some secondary item in the OP, just a link. This step in the OP would have been helpful to reproduce.

I don't use the TOC sidebar.
I don't find any option in the View menu for a "TOC sidebar".
Firefox Help, as usual (99%+), is no help, not mentioning any TOC Sidebar.
Searching the Web for "firefox+toc+sidebar" produced no results .

Please advise how to enable this (apparently) highly-secret toolbar, and what it is and does, thank you.
Although therube's confirmation should be enough, I'd like to see it, too. Thanks.

[Thrawn]

I can see what the OP is talking about.

That page includes an anchor tag with name "#alert()". While you're on the page, you can type

Code: Select all

https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIPromptService#alert()


into the address bar, and you're OK; it takes you to the point on the page that documents the 'alert' method. But if you then reload the page, or if you type in that URL while on any other site (including a blank tab), you get an XSS warning.

It's not really wise to use parentheses in an anchor name...and this is on developer.mozilla.org!

[Tom T.]

I took "Sidebar" to mean a toolbar, which many users do have. "Table of Contents" would have been more clear.

Agree that it's a site coding problem, not an NS problem. The sanitized URL provided by NS's XSS protection would be a better one to use for that link.

btw, this was unreproducible on Old, Unimproved Fx 3.6.28, regardless of how many iterations, blank tab, etc.
Just another of the hundreds of regressions in New! Improved! F4+.

[obiwan]

It's not really wise to use parentheses in an anchor name...

Why not? It's a perfectly valid anchor name as far as I can see.

Agree that it's a site coding problem, not an NS problem. The sanitized URL provided by NS's XSS protection would be a better one to use for that link.

Actually, I disagree that it's not a NoScript problem, it seems like an obvious false positive to me.

The real issue here is that NoScript's anti-XSS feature is not very sophisticated, because it filters any suspicious URLs regardless of whether they really are dangerous or not. It's unable to distinguish between a false positive and a real risk.

[therube]

Parens are valid.
Though the usage of "alert()" (a JavaScript function) is dangerous, XSS vulnerabilities & whatnot. And just what NoScript's XSS is out to prevent .

Valid:
http://msdn.microsoft.com/en-us/library/aa752574(VS.85).aspx

Though if you can finagle something like this, then it becomes dangerous.
http://msdn.microsoft.com/en-us/library/aa752574(VS.85).aspx#alert("hi")


> It's unable to distinguish between a false positive and a real risk.

Suppose that would depend on whether the site you happen to run into is vulnerable to XSS exploits.
And how is one to determine that?

[Thrawn]

It's not really wise to use parentheses in an anchor name...

Why not? It's a perfectly valid anchor name as far as I can see.

It's legal, but it's not wise, because there are filters like NoScript and PHP-IDS that will flag it as suspicious. There's nothing illegal happening in this webcomic, but...

Agree that it's a site coding problem, not an NS problem. The sanitized URL provided by NS's XSS protection would be a better one to use for that link.

Actually, I disagree that it's not a NoScript problem, it seems like an obvious false positive to me.

The real issue here is that NoScript's anti-XSS feature is not very sophisticated, because it filters any suspicious URLs regardless of whether they really are dangerous or not. It's unable to distinguish between a false positive and a real risk.

That depends on what you mean by 'false positive'. NoScript's filters are actually very sophisticated at distinguishing a potential attack from a request that just happens to contain special characters. If something gets filtered, then it was probably capable of being executed as an attack on a site that doesn't properly sanitise requests, and if a site is deliberately injecting scripts - XSS by design - then an attacker can do the same, thus there is a 'real risk'. If a particular site does properly sanitise everything, and the filtering breaks it, and you know how to write regular expressions, then OK, you can add an exception to the XSS filter (Options-Advanced-XSS). In this case, you'll get a warning, but the filtered link will still work, so I'd leave it as-is.

[Tom T.]

When all else fails, read the instructions.

XSS FAQ 4.8:

Cross-site requests from a trusted site to a different trusted site are checked through the InjectionChecker engine, which is more accurate and sanitizes only requests which contain conspicuous fragments of HTML or syntactically valid JavaScript.

So there you go.

I expected Thrawn's link to lead to this one.