Do browsers XSS filters protect against DOM based XSS?

Question

Many (but not all) browsers come with built in XSS protection that can be activated with a HTTP header:

X-XSS-Protection: 1; mode=block

As I understand it, it prevents reflected XSS attacks by checking that the document does not contain any fishy looking parts of the query string as it loades. For a modern SPA this is not very useful. The HTML loaded directly from the server is often just static, and all the interesting stuff happends after the page has loaded.

Are there any browsers that have XSS filters that also prevents DOM based XSS? A filter like that would for instance check that something passed to .innerHTML is not a malicious reflection from the query string or any other user input, like a textbox.

Is this a thing? Do I have anything to gain from enabling the XSS filter on a SPA?

Answer 1

I do not believe there is anything in any browser exactly like what you are describing. However a Content Security Policy could accomplish what you are looking for, in a more-robust way.

For example, if your CSP prevents inline scripting you could effectively prevent any JavaScript passed to innerHTML from executing. Note that script tags are normally stripped from innerHTML, but the CSP would also prevent any inline on* attributes from executing. This does of-course mean you won't be able to use inline scripting yourself (at-least without explicitly allowing specific script content), but that's generally considered good practice anyhow.

Answer 2

It may be possible by having a static analysis engine inside browsers; by considering its false positives, it becomes impossible.

None of the current prevention (XSS filters, CSP) will not be able to protect against the variations of DOM-based XSS such as:

• $(document.location.hash.slice(1)): vulnerability in jQuery
• eval("prompt('code')"): by considering the meaning of DOM, we need to call this kind of XSS with a different name such as memory-based JavaScript injection.

A good reference on DOM-based vulnerability variations: https://portswigger.net/web-security/dom-based

I think it would be necessary to completely stop! access to user inputs such as window.location, document.cookie, document.referrer, ... and it's impossible.

Answer 3

Trusted Types are coming to get rid of DOM XSS.

There are various implementations of them, including Chrome future features:

google-chrome-unstable --enable-blink-features=TrustedDOMTypes --enable-experimental-web-platform-features

Or separate polyfill: https://github.com/WICG/trusted-types

Or even tinyfill like this: TrustedTypes={createPolicy:(n, rules) => rules}

Detailed description available here: https://gadgets.kotowicz.net/poc/Trusted_Types_TPAC_2018.pdf