Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
DOM XSS and client prototype pollution-based XSS have one thing in common, we are modifying the pre-existing JavaScript code to popup an alert(1). Will CSP mitigate XSS in this case? Theoretically, JavaScript is already there and we aren't inserting new JavaScript, just modifying the existing code, so it makes sense that CSP won't have an effect, or are browser smart enough to prevent those variants of XSS?
External Links: An example of client-side prototype pollution based xss
I have done some research and found out CSP does block client side prototype pollution based XSS: XSS with CSP bypass. Similarly, DOM XSS case was different. When I used this code, saved at example.html
<!DOCTYPE html>
<html>
<head>CSP</head>
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
<meta http-equiv="Content-Security-Policy" content="default-src 'none'">
<body>
<script>eval(document.location.hash.slice(1))</script>
<h1>CSP</h1>
</body>
</html>
This payload popped alert(1): https://ba0c7a11a30b.ngrok.io/example.html#alert(1) but when I used this code, saved as example.php
<?php
header("content-security-policy: default-src 'none'; script-src 'self' 'unsafe-hashes';")
?>
<!DOCTYPE html>
<html>
<head>CSP</head>
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
<meta http-equiv="Content-Security-Policy" content="default-src https:">
<body>
<script>eval(document.location.hash.slice(1))</script>
<h1>CSP</h1>
</body>
</html>
it didnt result in alert(1). So I would say in most cases CSP mitigates DOM XSS and prototype pollution based xss.
<head> sect allowed only specific tags, so remove CSP word. 2: <meta http-equiv="Content-Security-Policy" can work in <head> section only, you have it out of DOM. 3:if you fix two above errs, you'll face with the third one - 2 meta-CSP tags means you have multiple CSPs act.Therefore all is disallowed in the page: scripts, styles, images, fonts, etc... from any sources. Multiple CSPs acts like as independent filters, so more restrictive one will apply, see csplite.com/csp/test23
Commonly, to perform client prototype pollution XSS, attacker need to have controlled script on the page, cos he need to inject code:
<script>
Object.prototype.srcdoc=['<script data-nononce>alert(1)<\/script>']
</script>
i.e. page is already under the control of the attacker.
Nonetheless Content Security Policy protects against client prototype pollution XSS, if inline scripts is disabled.
Also CSP has great possibilities to protect against any DOM XSS - a new require-trusted-types-for and trusted-types directives. But only Chrome supports those on the moment, and you need to rewrite all JS code to use Trusted Types framework.
