Introduction
Content security policy (CSP) is a computer security standard that adds a layer of protection against cross-site scripting (XSS), clickjacking, and other client-facing data injection attacks. These attacks are utilized for everything by hackers, from stealing data and site defacement, to spreading malware and causing havoc to web applications by impersonating the users.
When the CSP is enabled in a web server, it sends an HTTP response header with a value containing the CSP policy. Based on the defined CSP policy, the browser restricts the resources (scripts, styles, and more) that a page can load as well as decides if a page can be framed by other pages.
Alternative to the CSP response header, the <meta> element of the HTML page can be used to configure a CSP policy; given in the example below. CSP with response header supports extra directives such as Content-Security-Policy-Report-Only and report-uri, frame-ancestors, and sandbox directives.
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src *; ">
In this article, we will discuss how to configure CSP in spring security applications and mitigate injection attacks.
Mitigating XSS attacks
XSS attacks have always been one of the most concerning cyber-attacks. CSP’s primary goal is to mitigate injection attacks like XSS and report them. A cross-site scripting attack occurs when attackers inject malicious scripts into the targeted website’s content, which is then added with dynamic content and delivered to a victim’s browser. The victim’s browser treats the malicious scripts as trusted ones and executes them. As a result, the malicious scripts can access any sensitive information like cookies, session tokens, and more stored by the browser and utilized for the wrong purpose within that site. Attackers also use XSS for malware distribution, rewriting websites content, causing issues on social networks, and phishing user data. Other web attacks directly target the applications themselves, whereas XSS targets the users of web applications by deceiving them.
CSP has a standardized set of directives that inform the browser on which sites can be trusted and which should not be. Using specifically defined policies, you can define browser content to effectively get rid of frequent injection vectors, reduce the attack surface, and remarkably minimize the risk of XSS attacks.
CSP directives
The CSP policy consists of support of over a dozen directives, such as image-src, script-src, style-src, and more.
To learn about the CSP directives in detail, kindly refer to this article.
Example 1:
The following directive will only allow scripts to be loaded from the same origin as the page itself.
script-src 'self'
Example 2:
The following directive will only allow scripts to be loaded from a specific domain.
script-src https://trustedwebsite.com
Example 3:
The following directive will only allow scripts to be loaded from a specific domain and its subdomains.
script-src *.trustedwebsite.com
Example 4:
The following directive will not allow any scripts to be loaded even it blocks the execution of inline scripts.
script-src 'none'
In this article, we used the security policy default-src 'none,' which tells the browser to load no resources (scripts/styles/images, and more) on the page. This is the most restrictive policy defined.
Reporting
The report-uri directive tells the browser to report the violations in a standard JSON structure to the mentioned endpoints. The endpoints need to be programmed to store these reports and process them as required. As an example, it can be implemented to trigger a mail to the admin reporting the violation along with requestor information. These reports can also be sent to publicly hosted reporting services.
Content-Security-Policy: default-src 'none'; report-uri /csp_report_parser/report;
Testing
For testing, we can use the Content-Security-Policy-Report-Only response header. With this header, the browser can only report the violations against the declared policy, but the page loads/executes the content normally. This configuration can be only be used for testing.
Content-Security-Policy-Report-Only: default-src 'none'; report-uri /csp_report_parser/report;
Spring security
Content security policy is not enabled by default in spring security. It needs to be configured as per the required security policies declared for the protected resources.
Add spring-boot-starter-security along with the spring-boot-starter-web to your dependencies in your pom.xml and then configure spring security to use a configuration that enables CSP.
Configuration for content-security-policy header
The following is the spring security java configuration which includes a response header called Content-Security-Policy as part of each http response. With this header browser you can block the restricted content and report the violation based on the declared policy.
The following is the sample static HTML of the application, which loads external script jQuery and executes an inline script that displays a message ‘csp test’ on the screen.
Once the application is deployed, if we load the demo page in the chrome browser, the page does not display the message ‘csp test’. The browser restricted the loading of the external script and even the execution of the inline script based on the security policy configured in the application, that is, default-src 'none'. We can see the following errors in the browser’s developer tools console (press ctrl+shift+I to open developer tools in Chrome browser).
The policy violation report sent to the configured report-uri endpoint for each violation (2 violations in this example) is as shown below.
Configuration for content-security-policy-report-only header
The following is the spring security java configuration which includes a response header called Content-Security-Policy-Report-Only as part of each http response.
Conclusion
We learned how to use CSP in the spring application to restrict injection attacks like XSS. CSP needs to be precisely defined based on the specific application security requirements, and third-party frameworks which are being used in that application. This is because some frameworks won’t support CSP or some support less restrictive CSP, as an example, the angular framework requires the directive 'unsafe-inline' for its framework to load its inline styles/scripts, and more.
CSP cannot be treated as the only protection mechanism against XSS. Good development practices should be followed, such as the ones mentioned in Cross-Site Scripting Prevention Cheat Sheet, and then include CSP as an additional security layer.
References
- https://docs.spring.io/spring-security/site/docs/5.0.x/reference/html/headers.html
- https://developers.google.com/web/fundamentals/security/csp
- https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
- https://www.kaspersky.com/resource-center/definitions/what-is-a-cross-site-scripting-attack
- https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
