therube wrote:Neat, http://news.cnet.com/, heh.
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.
These examples only work if also davidlynch.org is whitelisted
therube wrote: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.
XSS sample with warning,
tlu wrote: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".
Giorgio Maone wrote: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Ðïåñ wrote:tlu wrote: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 wrote: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.
tlu wrote: I wonder if this technique can't be used for a new class of attacks
Giorgio Maone wrote: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.
tlu wrote:That's really great! Giorgio, thank you very much!!
Users browsing this forum: Google [Bot] and 7 guests