Content Security Policy
What is CSP :
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks,including Cross-Site Scripting (XSS) and data injection attacks. The Content-Security-Policy header allows you to restrict which resources such as JavaScript, CSS, Images, etc.) can be loaded, and the URLs that they can be loaded from. This ensures that we are loading the trusted resources thus securing our web page from being vulnerable to malicious scripts.
What is cross site scripting :
For understanding the role of CSP it is essential to first understand what is Cross site scripting and how the vulnerablities of a web page are exploited for attacks. Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim’s browser, the attacker can fully compromise their interaction with the application.
For example,
Following is the url for displaying the name of the user on profile page passed via a request param from url
https://testing.com/profiles?userName=tinaWhen another user of the application visits the malicious user’s profile, their browser will see the malicious code and execute it. That gives the malicious user control over the application’s execution context in the victim’s browser. To exploit such a vulnerability, the attacker can use a variety of payloads.
With such a vulnerability on the website
- You can use it to “steal someone’s session” and effectively log in as them. Meaning you can take over people’s account (somewhat).
- • You can send a malicious link to scare other people into doing things you want (‘Your computer has been hacked!! Download this (fake) antivirus’).
- • You could use it to read everything private that they’re doing and then blackmail them. You could use it to read all the HTML elements on that page and wait till they type in their credit card information or something else sensitive.
How does CSP help :
Content Security Policy is a mechanism for enforcing what content (scripts,styles,fonts,images,etc) can be loaded and used by a website. It helps you control various things, such as whether external scripts can be loaded and whether inline scripts will be executed. By only allowing certain origins to be the source of javascript(and explicitly not allowing inline javascript) we can reduce the amount of allowed executable javascript.The goal is to reduce the amount of allowed executable javascript to the point that only the javascript that can be executed is the javascript we originally intended.
To achieve that, CSP enforces restrictions on which script code can be executed.
An example CSP as follows :
Content-Security-Policy: default-src 'self"; img-src "self' cdn.example.com;This policy specifies that resources such as images and scripts can only be loaded from the same origin as the main page. So even if an attacker can successfully inject an XSS payload they can only load resources from the current origin. This greatly reduces the chance that an attacker can exploit the XSS vulnerability.
To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header.
This is a header which is added to all the Http requests received by the server. This is facilitated by a filter added in Spring security filter which adds this particular header then reflected in all the requests.
For example, a page that uploads and displays images could allow images from anywhere, but restrict a form action to a specific endpoint. A properly designed Content Security Policy helps protect a page against a cross-site scripting attack.
CSP directives :
While there is a huge list of available CSP directives which can be found here
but script-src is the most important one. It specifies valid sources for loading a javascript. Self is a keyword that means that resources can be loaded from the same origin. This includes urls not only loaded directly into script elements but also in-line event handlers.
Following CSP allows scripts to be loaded only from example.com
Content-Security-Policy: script-src https://example.com/Whereas following script is blocked and won’t be executed
<script src="https://not-example.com/"></script>With the above script inline event handlers will be blocked as well
<button id="btn-id" onclick="doSomething()"></button> Here the onclick function will not be executed. It disallows all inline javascript functions and mandates that all javascript must come from a trusted source only so even if an attacker injects an XSS into your web page, it won’t execute.
But adding following part to the CSP will execute the above code :
Content-Security-Policy: script-src 'unsafe-inline'When you put ‘unsafe-inline’ in the script-src of a content security policy, you are effectively disabling the most important part of content security policy. Content Security Policy was built to combat Cross Site Scripting by requiring that you can only load javascript from a specifically trusted origins. But when you put in ‘unsafe-inline’ you are allowing javascript back into the HTML, which makes XSS possible again.
For the above code to be CSP compliant we can change it to following :
document.getElementById("btn-id").addEventListener("click", doSomething);The best way is to move the inline javascript into a .js file and then include it on your webpage. Then it is no longer inline. The above code will be part of a app.js file which can then be imported.
The recent versions of Primefaces provides it’s support for CSP where you can enable the CSP support for Primefaces application by adding a context param for the same
<context-param>
<param-name>primefaces.CSP</param-name>
<param-value>true</param-value>
</context-param>PrimeFaces has chosen to support the NONCE (number used once) based checking for script evaluation only. Nonce attributes are automatically added to all script tags discovered by PrimeFaces. Nonce attributes are composed of base64 values and are verified against the nonce sent in the CSP header, and only matching nonces are allowed to execute.
For more information :
https://primefaces.github.io/primefaces/8_0/#/core/contentsecuritypolicy
Unsafe-eval :
Content-Security-Policy: script-src 'unsafe-eval'Unsafe eval controls several script execution methods that generate code from string. If we have CSP enabled and do not have unsafe-eval added as part of script-src directive following methods will be blocked :
eval()Function()- When passing a string literal like to methods like:
setTimeout("alert(\"Hello World!\");", 500); setTimeout()setInterval()window.setImmediate
The unsafe-eval keyword enables javascript code to be executed from strings which can be used by attackers to inject malicious code into webpage. Eval in every language means “take this string and execute it code.” Sure, you may be using eval in a semi-safe way, but as long as you allow it at all, you are saying “anyone is allowed to execute arbitrary code in my application given an entry point”. Many languages depend on such string handling for triggering inline events but it is always important to find alternatives for securing the application.