CSP: style-src unsafe-hashes

Content Security Policy (CSP) is a powerful feature in modern browsers that helps prevent attacks such as Cross-Site Scripting (XSS) and code injection. However, improper implementation of CSP can create vulnerabilities in the web application. One of such vulnerabilities is 'CSP: style-src unsafe-hashes'. This vulnerability is reported by an external vulnerability scanner when a web application has a Content Security Policy that allows inline styles using unsafe-hashes.

The 'unsafe-hashes' keyword is used to allow inline styles, but it also allows any inline style to be injected, including malicious styles. This vulnerability can allow attackers to execute XSS attacks, inject malicious code, and steal sensitive information. Therefore, it's crucial to fix this vulnerability as soon as possible.

In this manual, we will discuss the steps to fix the 'CSP: style-src unsafe-hashes' vulnerability.

‍

Step 1: Understand the Cause of the Vulnerability

Before we can fix the vulnerability, we need to understand why it's happening. The 'CSP: style-src unsafe-hashes' vulnerability is caused by an incorrect configuration of the Content Security Policy. The CSP should be configured to disallow inline styles and instead use external stylesheets.

However, in some cases, inline styles are necessary, and the CSP can be configured to allow them using the 'unsafe-hashes' keyword. The problem arises when the 'unsafe-hashes' keyword is used without specifying the allowed hashes. This allows any inline style to be injected, including malicious styles.

‍

Step 2: Review the Current CSP Configuration

The next step is to review the current CSP configuration to determine if it's allowing 'unsafe-hashes.' This can be done by inspecting the HTTP response headers of the web application.

To do this, open the Developer Tools in your browser, and go to the Network tab. Reload the web application, and you should see a list of requests and responses. Look for the response headers for the main HTML document, and locate the 'Content-Security-Policy' header.

The 'Content-Security-Policy' header should have a value that specifies the allowed sources for various types of resources, including stylesheets. Look for the 'style-src' directive, which specifies the allowed sources for styles. If the 'style-src' directive includes the 'unsafe-hashes' keyword without any allowed hashes, then the web application is vulnerable to the 'CSP: style-src unsafe-hashes' vulnerability.

‍

Step 3: Update the CSP Configuration

The next step is to update the CSP configuration to fix the vulnerability. The first option is to remove the 'unsafe-hashes' keyword from the 'style-src' directive. This will disallow all inline styles and force the web application to use external stylesheets. However, this may not be practical in some cases, as inline styles may be necessary for certain features.

The second option is to allow 'unsafe-hashes' but specify the allowed hashes for inline styles. This will ensure that only the specified inline styles can be injected and prevent malicious styles from being executed.

To specify the allowed hashes, we need to generate the hash value for each inline style. This can be done using a hash generator tool such as the one provided by Google.

For example, suppose we have the following inline style in our web application:

<div style="background-color: red;"></div>

We can generate the SHA-256 hash value for this style using the hash generator tool. The resulting hash value is

‍'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng='.

We can then update the 'style-src' directive in the CSP header to include the allowed hash value as follows:

Content-Security-Policy: style-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng='

This configuration allows inline styles that match the specified hash value and disallows all other inline styles.

We need to repeat this process for each inline style in the web application and specify the allowed hash values in the 'style-src' directive.

‍

Step 4: Test the Updated CSP Configuration

After updating the CSP configuration, it's crucial to test the web application thoroughly to ensure that it's working as expected and the vulnerability has been fixed.

We can use a CSP evaluator tool to check the CSP configuration and ensure that it's properly configured to prevent the 'CSP: style-src unsafe-hashes' vulnerability. The tool can be used to simulate various attack scenarios and test the CSP configuration's effectiveness.

Additionally, we should also perform manual testing to ensure that the web application is functioning correctly and there are no unintended side effects of the CSP configuration changes.

‍

Step 5: Monitor the CSP Configuration

Even after fixing the 'CSP: style-src unsafe-hashes' vulnerability, it's crucial to monitor the CSP configuration regularly.

As the web application evolves, new inline styles may be added, and the CSP configuration needs to be updated accordingly. Additionally, changes in the web application's architecture, such as new third-party integrations, may require updates to the CSP configuration.

Regular monitoring and maintenance of the CSP configuration can help prevent future vulnerabilities and ensure that the web application is secure.

‍

Conclusion

The 'CSP: style-src unsafe-hashes' vulnerability can pose a significant risk to web applications by allowing attackers to execute XSS attacks and inject malicious code. However, it can be fixed by properly configuring the Content Security Policy to disallow all inline styles or specify the allowed hashes for inline styles.

By following the steps outlined in this manual, web application owners and developers can effectively fix the 'CSP: style-src unsafe-hashes' vulnerability and ensure that their web applications are secure.

‍