Blocking Cross-site scripts (XSS)

[valodiadeseynes]

Does uMatrix block XSS like NoScript does?

If not, is it possible to add this feature, or is this even needed at all?

[gorhill]

Block 3rd-party sites by default, i.e. work in default-deny mode. uMatrix with out-of-the-box setting protects you. since only passive 3rd-party content is allowed (css, images).

[orbisvicis]

Sometimes: "Furthermore, NoScript's sophisticated InjectionChecker engine checks also all the requests started from whitelisted origins for suspicious patterns landing on different trusted sites: ..."

So if you allow a script from a 3rd party site (trusted) which is later compromised, noscript claims be likely to detect that. Also, if the malicious script is entirely embedded within the 1st party site (is this technically xss?), then noscript can be configured to detect that by setting noscript.injectionCheck to "check every request*.

Plugins that try to do too much screw over users when they become partially obsolete. I wish noscript's "InjectionChecker" engine would be repackaged as a standalone extension.

Kinda uncertain regarding umatrix'es unrelated settings (strict https, spoof user agent, clear browser cache, delete non-blocked session cookies).

Anyway noscript can be run in "allow scripts globally mode" to access its ancillary features such as XSS/CSRF protection.

edit: actually, I don't think noscript's ABE provides any additional CSRF protection over umatrix, if you properly block the correct xhr 3rd parties.

[ThrawnCA]

If you're going to use NoScript and µMatrix together, then you might want to consider setting NoScript to ‘Cascade top-level document's permissions to third-party sites’.

[orbisvicis]

If umatrix is used with noscript in "allow scripts globally mode", then "cascade top-level document's permissions to third-party sites" has no effect, I presume?

[ThrawnCA]

Correct. Allowing scripts globally makes most of the other script settings redundant.

However, cascading permissions might be a better choice when combining with uMatrix. Then, NoScript will control the permissions of the top-level site (including inline scripts), and once it's allowed, uMatrix will control all the third parties.

[gorhill]

cascading permissions might be a better choice when combining with uMatrix

What is the advantage of NoScript's "cascading permissions" over adding the global rule * * script block ...

... then allowing on a per-site basis all non-blacklisted scripts (1st- and 3rd-party ones) with two clicks to toggle the script cell to allow ...

... ?

[ThrawnCA]

Does that cover inline scripts? If so, it's pretty close.

I believe uMatrix doesn't handle data: URIs, though? PoC at http://evil.hackademix.net/hsb/

Also, NoScript has the option to distinguish protocols (eg only allowing the HTTPS version of a site to run scripts).

[berrythesoftwarecodeprogrammar]

that page pwnd me with noscript set to allow all scripts and ublock and umatrix blocking scripts D:

[berrythesoftwarecodeprogrammar]

this is all the logger shows:

13:24:45        --  script  http://evil.hackademix.net/hsb/{inline_script}
13:24:44            doc http://evil.hackademix.net/hsb/

it reports that the inline script was blocked but it still works

[berrythesoftwarecodeprogrammar]

<meta http-equiv="refresh" content="0;url=data:text/html,<script>alert('PWND!!! :)')</script>">

is the source. you dont even see it with Live HTTP Headers. kinda stupid that it can get around the browser like that and execute javascript

even with data-scheme blocked by default in umatrix and ublock it gets through

[berrythesoftwarecodeprogrammar]

i just found out about accessibility.blockautorefresh = true but it doesnt show where the refresh would go if you choose to follow it

[ThrawnCA]

"So if you allow a script from a 3rd party site (trusted) which is later compromised, noscript claims be likely to detect that."

Well, it depends on what kind of "compromise" you mean. That's not really what XSS is about.

The much more likely scenario is: you trust bank.com, but it turns out to have a weakness that allows random.com to send crafted requests that execute scripts in the context of bank.com, reading your session cookies and making transactions on your behalf. NoScript claims to be good at catching the crafted requests and neutralising them.

uMatrix has a very good chance of catching the attack, too, because why would you have allowed random.com to send requests to bank.com? Although if you're in the habit of switching off the matrix for some sites, then you may have trouble.

"Also, if the malicious script is entirely embedded within the 1st party site (is this technically xss?)"

Certainly it is. It's called Persistent XSS, aka type 2 (I think), and it's quite nasty (Samy worm anyone?). Typically happens on sites like wikis or forums (or Github?) that store and display snippets of user-provided content.

NoScript can't catch it directly, since the crafted request happened earlier in the attacker's session. However, such attacks typically have limited space, so they rely on pulling down payloads from other sites. Which will probably not be trusted, so the attack would fail.

"I wish noscript's "InjectionChecker" engine would be repackaged as a standalone extension."

Well, it's GPL-licensed, so feel free...although there is an advantage to incorporating it within NoScript itself. Putting every request through InjectionChecker has overheads. NoScript reduces this by applying a simpler and harsher check to requests originated by untrusted sites.