XSS examples not blocked by Noscript?

[tlu]

I just learned about

http://davidlynch.org/blog/2011/10/xss-is-fun/

which provides some XSS examples for several popular websites.

These examples only work if also davidlynch.org is whitelisted so we are protected by default. Nevertheless, shouldn't the XSS filter of Noscript stop these examples even if the originating site is whitelisted?

[therube]

Neat, http://news.cnet.com/, heh.

[tlu]

Neat, http://news.cnet.com/, heh.

Yes, all of these examples are funny. But since http://noscript.net/features#xss says:

Furthermore, NoScript's sophisticated InjectionChecker engine checks also all the requests started from whitelisted origins for suspicious patterns landing on different trusted sites: if a potential XSS attack is detected, even if coming from a trusted source, Anti-XSS filters are promptly triggered.

.... we shouldn't be able to see them, or, at least, we should get a warning. Or am I missing something?

[therube]

These examples only work if also davidlynch.org is whitelisted

Actually both davidlynch.org & the "host" domain need to be Allowed.
And given that, I suppose that is why NoScript does not notify.

One would not normally allow davidlynch.org & so in these cases the exploit would never occur.
If you were not a NoScript user, JavaScript would be allowed everywhere, in all cases, so his exploits would "just work".
Being a NoScript user, his exploits fail.
In order to force the exploit to work, you need to allow both domains, & in doing so it is no longer an exploit (to NoScript) because you have allowed (agreed) to be exploited.


XSS sample with warning, here.


Actually his exploit code looks to not work in IE8?

[tlu]

These examples only work if also davidlynch.org is whitelisted

Actually both davidlynch.org & the "host" domain need to be Allowed.

That's what i wrote above.

And given that, I suppose that is why NoScript does not notify.

I think it should considering the quotation in my last post.

One would not normally allow davidlynch.org & so in these cases the exploit would never occur.

Absolutely. The question is only why the Noscript InjectionChecker doesn't recognize the request as a potential XSS attack "even if coming from a trusted source".

XSS sample with warning,

Yes, that's what I expected to see.

[Giorgio Maone]

If you looked at the attack URLs, e.g

http://www.foxnews.com/eyewonder/interim.html?src=http://davidlynch.org/projects/xss/eyewonder.js

you'd see that NoScript's XSS filter can't do anything specific to block them, because otherwise no redirection service or any other web application which takes absolute URLs as parameters (e.g. URL shorteners, or any blog comment form) would work.

The problem here is the incredible stupidity of the developers of those sites, which have implemented their page to load any script whose address is passed as the src query string parameter.
In other words, no Javascript code is passed in the request, just an "innocent" URL which the page idiotically turns into a script source.

Fortunately enough, as you noticed, this kind of setup (which bypasses any XSS filter because it's technically not a "regular" XSS) still cannot work unless the attacker's script source (which necessarily belongs to an URL different than the attacked site) is allowed.

[GµårÐïåñ]

Absolutely. The question is only why the Noscript InjectionChecker doesn't recognize the request as a potential XSS attack "even if coming from a trusted source".

I guess you don't get what TRUSTED means which is to say that you are allowing it to do whatever because you TRUSTED it. Script injections are not that uncommon even by legitimate sources, and if you TRUST them, they can do it, if you don't, they can't. Simple enough, so I don't get why you are not getting this. If you have to allow a bad site for it to screw you over, then it was working just as it should and YOU chose to TRUST it to do what it needs to screw you over. Are we missing something here?

[Giorgio Maone]

tlu is right in his understanding that NoScript's XSS filters blocks XSS attacks even if they come from a source which is in your scripting whitelist.
In this case, though, this doesn't happen because there's no XSS payload to be stripped but just a URL which the victim site idiotically uses as a reference to an external script source.

[GµårÐïåñ]

tlu is right in his understanding that NoScript's XSS filters blocks XSS attacks even if they come from a source which is in your scripting whitelist.
In this case, though, this doesn't happen because there's no XSS payload to be stripped but just a URL which the victim site idiotically uses as a reference to an external script source.

Correct, not arguing that. But anytime you have to have to explicitly allow something to work, even if it happens to be bad coding by the site, to have the exploit work on it, then the security tool is still preventing it even if using a different vector (in this case blocking a different domain and not letting it be governed by the trusted status of the idiot site) which may not be using the XSS engine because it doesn't qualify as one but still the protection is there none the less unless you allow it to take advantage of that exploit.

[tlu]

Absolutely. The question is only why the Noscript InjectionChecker doesn't recognize the request as a potential XSS attack "even if coming from a trusted source".

I guess you don't get what TRUSTED means which is to say that you are allowing it to do whatever because you TRUSTED it. Script injections are not that uncommon even by legitimate sources, and if you TRUST them, they can do it, if you don't, they can't. Simple enough, so I don't get why you are not getting this.

Because you're much more intelligent than I am?

If you have to allow a bad site for it to screw you over, then it was working just as it should and YOU chose to TRUST it to do what it needs to screw you over. Are we missing something here?

Yes, you are. There must be a reason why Giorgio constructed the XSS filter in such a way that it also blocks XSS attacks coming from trusted sites. It it were that simple as you suggest this wouldn't have been necessary. And if I remember correctly, this feature didn't exist in earlier versions - it was introduced later. Again, there must be a reason why.

Anyway, it's a built-in feature, and my only question was why it doesn't work in these examples. "Simple enough, so I don't get why you are not getting this."

[tlu]

you'd see that NoScript's XSS filter can't do anything specific to block them, because otherwise no redirection service or any other web application which takes absolute URLs as parameters (e.g. URL shorteners, or any blog comment form) would work.

The problem here is the incredible stupidity of the developers of those sites, which have implemented their page to load any script whose address is passed as the src query string parameter.
In other words, no Javascript code is passed in the request, just an "innocent" URL which the page idiotically turns into a script source.

Thanks, Giorgio for this explanation. I understand what you're saying, and I agree that risk is low as Noscript blocks it by default (= if the origination site isn't whitelisted). Nevertheless, I wonder if this technique can't be used for a new class of attacks if an attacker succeeds to manipulate the originating site which might be a trustworthy and, thus, whitelisted website. In those examples the results were only funny, but other outcomes are conceivable.

[Giorgio Maone]

I wonder if this technique can't be used for a new class of attacks

Fortunately it's a very limited "class" of attacks, since using a parameter as the script source is something so stupid that I've never seen it before and hopefully will never see again (any developer with a clue understands that). The fact we're seen it on multiple sites at the same times is just due to their reliance on the same buggy tool.

That said, I'm gonna implement in next dev build a further (pretty unique) mitigation, which can neutralize this attack even if the injected script source comes from a trusted origin.

[tlu]

That said, I'm gonna implement in next dev build a further (pretty unique) mitigation, which will neutralize this attack even if the injected script source comes from a trusted origin.

That's really great! Giorgio, thank you very much!!

[saywot]

That's really great! Giorgio, thank you very much!!

+1
because strictly XSS or not, buggy tool or not, NS runs on this system to anticipate both the dangerous and the dumb.
Giorgio, we've already donated but not even the most expensive proprietary software offers such generous support as you and your team.
NS is priceless.

[Giorgio Maone]

Please check latest development build 2.1.8rc1