InformAction Forums

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: Without NoScript: With NoScript: Without NoScript: With NoScript: Without NoScript:

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

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

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.

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.

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

Giorgio Maone wrote: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:
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.

carverrn wrote:

Giorgio Maone wrote: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
(notice the "@", meaning that we match the origin rather than the destination)

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