CSP: script-src unsafe-eval

Content Security Policy (CSP) is an HTTP response header that allows website administrators to control the resources (e.g., scripts, stylesheets, and fonts) that a browser can load from a web page. CSP is designed to protect websites from cross-site scripting (XSS), clickjacking, and other code injection attacks.

The 'CSP: script-src unsafe-eval' vulnerability is a type of CSP violation that occurs when a website allows the use of the 'unsafe-eval' keyword in the script-src directive. The 'unsafe-eval' keyword allows JavaScript code to be executed from strings, which can be used by attackers to inject malicious code into a web page.

To fix the 'CSP: script-src unsafe-eval' vulnerability, you will need to modify the CSP policy of your web application to remove the 'unsafe-eval' keyword from the script-src directive. This can be done by following these steps:

‍

Step 1: Understand your current CSP policy

The first step in fixing the 'CSP: script-src unsafe-eval' vulnerability is to understand your current CSP policy. You can check the CSP header of your website using the developer tools of your browser.

For example, if you are using Google Chrome, you can open the developer tools by pressing F12 or by right-clicking on the web page and selecting 'Inspect'. Then, select the 'Network' tab and reload the page. You should see the HTTP response headers of the page in the bottom panel.

Look for the 'Content-Security-Policy' header in the list of headers. If the header is not present, then your website does not have a CSP policy, and you should add one. If the header is present, check the value of the 'script-src' directive. If it contains the 'unsafe-eval' keyword, then your website is vulnerable to the 'CSP: script-src unsafe-eval' vulnerability.

‍

Step 2: Modify your CSP policy

To fix the 'CSP: script-src unsafe-eval' vulnerability, you need to remove the 'unsafe-eval' keyword from the script-src directive of your CSP policy. You can do this by modifying the CSP header of your website.

There are several ways to modify the CSP header of your website, depending on your web server and programming language. Here are some examples:

Example 1: Apache web server with mod_headers module

If you are using the Apache web server with the mod_headers module, you can add or modify the CSP header in your .htaccess file or your virtual host configuration file.

To remove the 'unsafe-eval' keyword from the script-src directive, add the following line to your configuration:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-1234567890'"

In this example, the 'default-src' directive allows resources to be loaded from the same origin as the website, and the 'script-src' directive allows scripts to be loaded from the same origin as the website and a nonce value of '1234567890'. The nonce value is a random string that is generated for each HTTP response and allows inline scripts to be executed while still enforcing the CSP policy.

Example 2: PHP with header() function

If you are using PHP, you can modify the CSP header using the header() function.

To remove the 'unsafe-eval' keyword from the script-src directive, add the following line to the top of your PHP script:

header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-1234567890'");

In this example, the 'default-src' directive allows resources to be loaded from the same origin as the website, and the 'script-src' directive allows scripts to be loaded from the same origin as the website and a nonce value of '1234567890'.

Example 3: Node.js with helmet module

If you are using Node.js with the helmet module, you can modify the CSP header using the helmet.contentSecurityPolicy() middleware.

To remove the 'unsafe-eval' keyword from the script-src directive, add the following line to your Node.js script:

const helmet = require('helmet');

app.use(helmet.contentSecurityPolicy({

directives: {

defaultSrc: ["'self'"],

scriptSrc: ["'self'", "'nonce-1234567890'"]

}

}));

In this example, the 'default-src' directive allows resources to be loaded from the same origin as the website, and the 'script-src' directive allows scripts to be loaded from the same origin as the website and a nonce value of '1234567890'.

‍

Step 3: Test your new CSP policy

After modifying your CSP policy, you should test your website to make sure that it still works as expected and that the 'CSP: script-src unsafe-eval' vulnerability is fixed.

You can use the developer tools of your browser to check if the CSP header has been updated and if the 'unsafe-eval' keyword has been removed from the script-src directive. You can also test your website by submitting malicious payloads that use the 'eval()' function or the 'new Function()' constructor to execute JavaScript code.

If your new CSP policy is working correctly, you should see CSP violations in the developer tools console when malicious payloads are submitted.

‍

Step 4: Monitor your CSP policy

Once you have fixed the 'CSP: script-src unsafe-eval' vulnerability, you should monitor your CSP policy regularly to ensure that it is still effective and that new vulnerabilities are not introduced.

You can use CSP reporting to receive reports about CSP violations that occur on your website. You can also use third-party CSP monitoring tools to monitor your CSP policy and receive alerts when new vulnerabilities are discovered.

‍

Conclusion

The 'CSP: script-src unsafe-eval' vulnerability is a serious security issue that can be exploited by attackers to inject malicious code into a web page. To fix this vulnerability, you need to modify the CSP policy of your website to remove the 'unsafe-eval' keyword from the script-src directive.

By following the steps outlined in this manual, you can fix the 'CSP: script-src unsafe-eval' vulnerability and protect your website from code injection attacks. Remember to test and monitor your CSP policy regularly to ensure that it is still effective and that new vulnerabilities are not introduced.

‍