Build in XSS filter in Pale Moon

[yes_noscript]

Pale Moon is working with Riccardo Pelizzi to implement an XSS filter in Pale Moon that is both more accurate than Chrome and with fewer false positives than NoScript.
Now i wonder if you guys can help to improve this or just give a opinion for that feature.

Current the PM test build is only available for beta tester but anyone can join the beta team.

[Thrawn]

That's generically good news, and I expect that Giorgio would be happy to look at their code (NoScript development is all his).

I do wonder a bit how the proposed filter will achieve less false positives, unless it's also less sensitive (you said it will be more accurate than Chrome, but will it be more accurate than NoScript?). I'm not sure that Giorgio would want to make that tradeoff. And what about the filter performance? Slow filtering is not just inconvenient, it's also prone to denial-of-service by requests that are carefully crafted to slow down the filter. Or poorly-coded advertising techniques that inadvertently trip the filter thousands of times with harmless-but-junk requests.

If it's actually fast, sensitive, and accurate, great! No doubt Giorgio would then be happy to incorporate aspects of it into NoScript, and/or use his influence to promote it for inclusion in mainline Firefox.

If you want to take a look at the InjectionChecker code in NoScript, feel free; it's free software (GNU GPL).

[Thrawn]

Is the proposed filter basically XSSFilt?

Just finished reading the paper. It does sound interesting, and if it can minimize false positives (and reduce their impact on page loads), then that does make it more suitable for mass usage.

The performance angle is definitely a concern; we already get reports of pages taking ages to load, usually due to poorly-designed ads, and yet the paper indicated that the overhead of the NoScript XSS filter is "trivial". I wonder whether it's possible to combine the two approaches to some extent, so checking the request would affect whether or not the filter bothers to examine the response. However, that would bring back the problem of dealing with disguised requests.

[yes_noscript]

Thanks for your feedback.
I have no idea how it works Its a new feature and only Moonchild and Riccardo Pelizzi knows how it works.

I also just copy&paste the info with is better, .. - i have no knowledge if this is true or not.
Also i ask Moonchild about XSSFilt. Thanks for that info!

[therube]

(Link to the Pale Moon forum thread ?)

[yes_noscript]

(Link to the Pale Moon forum thread ?)

https://forum.palemoon.org/viewtopic.php?f=20&t=10378
But as i said, its only for beta members. So you need to join the team first.

Anyway i get this answer from Moonchild to your question:
Yes it is basically XSSfilt by Riccardo Pelizzi and his colleague who wrote the paper.

[therube]

Oh, didn't realize the thread wasn't public.

[Thrawn]

Well, it will at least avoid pitfalls such as this, since it's hooking into the JavaScript engine.

Although - I wonder whether the fuzzy string matching will account for this? Probably worth mentioning to Riccardo.

[Thrawn]

There is a public thread now.

[Thrawn]

There's an interesting threat category mentioned in the XSSFilt research paper, which XSSFilt can catch and NoScript doesn't: script tags pointing to user-input-controlled URLs. Not exactly the same as XSS, since the scripts will execute with the correct origin; however, being able to force pages to load script from arbitrary locations is still a significant vulnerability.

I guess it's less of an issue when running NoScript, though, since attacker-controlled domains are probably blocked.

[yes_noscript]

I use the internal Pale Moon XSS Filter with NoScript and i didn't see any problems with that combo.
So yes, it works great.

One big security improvement other Gecko based browsers didn't have.

[yes_noscript]

The buildin XSS filter doesnt work since PM 27 and the dev (Riccardo) do not make any update for it:
https://forum.palemoon.org/viewtopic.ph ... 11#p107111

Also the XSS filter is removed in 27.0.0 (2016-11-22) because it was prone to some instability and needs to be rewritten.