0

I am doing some background research into types of XSS and prevention and as I understand it there is not much any application can do against a universal XSS in a plugin or browser.

A last line of defense for XSS vulnerabilities is a good content security policy header set. It won't get rid of the underlying vulnerability but prevents an attacker from effectively exploiting it. For example, the following policy only loads scripts from the same origin as the webpage:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-src 'none'; base-uri 'none';

As this is browser-based protection for a web application, I would think it would not mitigate any risk from a universal XSS as it affects the browser and so could bypass the protections. This leaves the only real mitigation for universal XSS as ensuring your browser and plugins are up to date.

Am I correct in my thinking? Appreciate any input.

Soufiane Tahiri
  • 2,667
  • 12
  • 27
TJSullivan
  • 3
  • 1
  • 2
    Does this answer your question? [XSS prevention through Content Security Policy](https://security.stackexchange.com/questions/38001/xss-prevention-through-content-security-policy) – Soufiane Tahiri Jan 19 '21 at 10:53
  • 1
    @SoufianeTahiri that dupe does not discuss universal XSS, which appears to be the focus here. – multithr3at3d Jan 20 '21 at 21:44
  • Yes universal XSS is a different beast and there's not much you can find about its mitigations online... – TJSullivan Jan 21 '21 at 09:29

2 Answers2

0

Yes, this is correct.

UXSS does not need a vulnerable web page in order to trigger, and can penetrate web sessions belonging to secure, well written web pages, thus creating a vulnerability where there isn’t one.

If an UXSS defect in the browser allows for injection of Javascript into arbitrary webpages (like this UXSS for Chrome Android) then the the XSS execution would still be respecting the CSP: script-src 'self'.

Kyle Fennell
  • 921
  • 4
  • 12
  • UXSS for Chrome Android you showed injects arbitrary javascript:URLs.It will be successfully blocked by CSP `script-src 'self'` rule because javascript:URLs requires `'unsafe-inline'`. – granty Jan 25 '21 at 15:16
0

No, this is not correct.

Third-party scripts can get to the page in a few ways:

  1. web page classic XSS vulnerability or universal (browser's) XSS
  2. browser plugun
  3. viruses on PC or home router
  4. hacking hosting
  5. injection by ISPs (internet service providers)
  6. DNS spoofing

CSP protects from injecting scripts independently the way how it was injected.
Furthermore, the CSP protects the page from the interference of specially created malicious browser plugins. So it will do this even in the case of vulnerabilities in regular plugins.

Thing is that with CSP the attacker is not enough to inject script, it have to get control over HTTP headers too. So it should be 2 vulnerabilities at once for that.

CSP is a powerful tool, if you know how to use it, you can even protect yourself from inserting scripts on behalf of the site itself ('self').
For example, the publishing of 2 CSP headers at once: script-src 'self' and script-src 'nonce-value' will acts as logical "AND".
It means that will be allowed only scripts from site's own domain and which have valid 'nonce=' attribute.
It will not be enough for a hacker to insert a external script, he needs access to the HTTP header and the 'nonce' value.

The main thing against XSS - do not use 'unsafe-inline' in the script-src directive. This protect against injecting any inline scripts (, inline event handlers and javascript:-navigation).
And you can additionally protects external scripts by using the 2 headers trick above or by using 'hash-value' token.

Also have a look on Trusted Types API, it's a separate CSP spec. Here is a demo how it works(Chrome browser only as for now). Trusted Types is effective against any XSS.

granty
  • 181
  • 3