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.

3
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'.

1
  • 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 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.