v1.9.7 getting "xss:xss@" inserted into URL

[carverrn]

This morning when I went to login to my webmail provider (runbox.com) using a secure URL I got a popup message saying ""Confirm: You are about to log in to the site secure.runbox.com with the username xss, but the website does not require authentication. This may be an attempt to trick you. Is secure.runbox.com the site you want to visit? Yes/No"

I talked to the folks at Runbox for a bit and the issue finally came around to if I was using any addons for Firefox and if any had been updated recently. And of course I said "yes, I'm using NoScript and it was just updated".

I started looking into it and when NoScript is not active, my secure login seems to fine. I used LiveHTTP and watch the information back and forth and all seemed ok.

When I run NoScript v1.9.7 it starts getting "xss:xss@" inserted into the URL.

Here are a few examples with/without NoScript:

With NoScript:

Code: Select all

https://xss:xss@secure.runbox.com/login.ttml?reason=no_cookie&destination=https%3A%2F%2Fsecure.runbox.com%2Fmail

Without NoScript:

Code: Select all

https://secure.runbox.com/login.ttml?reason=no_cookie&destination=https://secure.runbox.com:443/mail

With NoScript:

Code: Select all

https://xss:xss@secure.runbox.com/_img/runbox_neg.gif

Without NoScript:

Code: Select all

https://secure.runbox.com/_img/runbox_neg.gif

With NoScript:

Code: Select all

https://xss:xss@secure.runbox.com/_css/stylesheet.css

Without NoScript:

Code: Select all

https://secure.runbox.com/_css/stylesheet.css

Is this a bug in the v1.9.7 version of NoScript?

[Giorgio Maone]

1. Are you using a proxy server?
2. Do you get any "[NoScript XSS]" message in Tools|Error Console?

[carverrn]

Thanks for the quick response!

1. Yes, it only seems to happen when I'm connected through our company proxy server.

2. Yes, there is a "[NoScript XSS]" message:

Code: Select all

[NoScript XSS] Sanitized suspicious request. Original URL [https://secure.runbox.com/login.ttml?reason=no_cookie&destination=https://secure.runbox.com:443/mail] requested from [file:///C:/Documents%20and%20Settings/carvern/Desktop/MYLINKS1.htm]. Sanitized URL: [https://xss:xss@secure.runbox.com/login.ttml?reason=no_cookie&destination=https%3A%2F%2Fsecure.runbox.com%2Fmail].

When I'm not going through the proxy server a similar "[NoScript XSS]" message occurs but without the "xss:xss@" in the "sanitized URL".

Regards,
Rich

[Giorgio Maone]

OK, it's expected then.
The "xss:xss@" prefix is an implementation artifact required for the URL for proxied requests to be modifiable during loading, and it should happen only if a XSS attempt is detected.
In this case, you've got a false positive seemingly due to the local link you're opening being not properly encoded.
Please try to replace "https://secure.runbox.com/login.ttml?re ... m:443/mail" with the properly encoded "https://secure.runbox.com/login.ttml?re ... com%2Fmail" in the MYLINKS1.htm file on your desktop.

[carverrn]

Actually, the link in my local file is "https://secure.runbox.com/mail"

The URL "https://secure.runbox.com/login.ttml?reason=no_cookie&destination=https://secure.runbox.com:443/mail" is a redirection that comes back from "https://secure.runbox.com/mail" so I can't change that.

[Giorgio Maone]

Alternate work-around, adding the following line to the NoScript Options|Avanced|XSS exceptions box:

Code: Select all

^file:///.*/carvern/Desktop/

[carverrn]

Alternate work-around, adding the following line to the NoScript Options|Avanced|XSS exceptions box:

Code: Select all

^file:///.*/carvern/Desktop/

That didn't work but adding this did:

Code: Select all

^https://secure.runbox.com

Maybe because the problem URL is a redirection coming from "https://secure.runbox.com" and not the original local file?

Thank you for the suggestion.

[Giorgio Maone]

Alternate work-around, adding the following line to the NoScript Options|Avanced|XSS exceptions box:

Code: Select all

^file:///.*/carvern/Desktop/

That didn't work

Sorry, should be

Code: Select all

^@file:///.*/carvern/Desktop/

(notice the "@", meaning that we match the origin rather than the destination)

[therube]

If both (& assuming) methods work, why would you choose & I presume the latter over the former?
Guessing a more restrictive policy?