InformAction Forums

Ello, I've noticed the below whilst combing through the Extension debug, and it would appear that I have no way of affecting change on these XSS settings that are built in.

xss/Exceptions.js

I can't post the code as it won't let me get it past the forum spam guard, unfortunately.

Have I read the intent here wrongly, or is this allowing (for example) Microsoft to run XSS unrestrictedly, for things like logins using a Microsoft ID? Oh, I can get a snippet of the code in, just not the full thing.

I realise that might be a bad example because it actually specifically says MSDN, but there's a bunch of stuff in there that I might not really want to have XSS.

I realise that we have to jump around a touch (here & here) to modify the XSS options that we *can* change, and I'm aware of the built in 'Allows' that come with the package, and the acceptible caveat given to including them. They're options that I can change. These I worry that I can't remove for whatever reason.

This isn't a 'shouting at noscript' thing, I'm just trying to find out how I can ensure there's no more of these, and to change the ones that I don't wish to have in there.

You could link to the code in Github - https://github.com/hackademix/noscript/ ... eptions.js

This sort of thing existed in NoScript Classic, but they were configurable there. Looks like the only way to get rid of these exceptions in NoScript Webext is to patch the code.

Ah! Nice one.

And ... OK, cheers ... Obviously I'm not sure that I'm up to that, talent-wise ... would I just maybe make a fork without the defaults, perhaps?
(I'd remove the other ones, too and call it NoScriptNoDefaults perhaps)

Or ... something else? Heh. Or did you mean, download, change the bits (safely), then run the add-on as a local xpi?

I'm still not entirely sure of what I'm looking at, tbh.

Mad_Man_Moon wrote: ↑Wed Mar 30, 2022 5:56 pm did you mean, download, change the bits (safely), then run the add-on as a local xpi?

This, at least until these exceptions become configurable again.

Mmm, thanks, mate.

Mad_Man_Moon wrote: ↑Wed Mar 30, 2022 4:50 pm

Code: Select all

      if (!srcOrigin && isGet) {
        if (/^https?:\/\/msdn\.microsoft\.com\/query\/[^<]+$/.test(unescapedDest)) {
          return true; // MSDN from Microsoft VS
        }
      }

No, this is meant to allow Visual Studio (or other applications installed locally) to run MSDN search query containing code snippets without triggering the XSS filter needlessly.
The check for empty srcOrigin is meant to avoid other pages to exploit (unlikely) vulnerabilities in the search engine.
This does not give any extra "XSS power" to Microsoft

Similarly the other exceptions are very limited in scope, carefully crafted not to expand the attack surface and meant only to allow commonly used services to work without blocking the browser with XSS false positives.

Cheers, Giorgio.

Giorgio Maone wrote: ↑Wed Mar 30, 2022 8:29 pm

Mad_Man_Moon wrote: ↑Wed Mar 30, 2022 4:50 pm

Code: Select all

      if (!srcOrigin && isGet) {
        if (/^https?:\/\/msdn\.microsoft\.com\/query\/[^<]+$/.test(unescapedDest)) {
          return true; // MSDN from Microsoft VS
        }
      }

No, this is meant to allow Visual Studio (or other applications installed locally) to run MSDN search query containing code snippets without triggering the XSS filter needlessly.
The check for empty srcOrigin is meant to avoid other pages to exploit (unlikely) vulnerabilities in the search engine.
This does not give any extra "XSS power" to Microsoft

Similarly the other exceptions are very limited in scope, carefully crafted not to expand the attack surface and meant only to allow commonly used services to work without blocking the browser with XSS false positives.