What is CSP?
CSP is Content Security Policy Header. CSP is a HTTP header sent by the browser to the user and it is supported by almost all the commonly used browsers. The primary goal of this header is to provide protection against XSS (Cross site scripting) attack and other content injection attacks. XSS vulnerabilities rank at the third place of the most critical web application security flaws provided by the renowned OWASP community (Open Web Application Security Project). Those script injections in a web page can lead to session hijacking or website defacing for example. CSP blocks these injection attacks by restricting the sources of content loading and content injections by the attacker to those only allowed or whitelisted by the developer.
Why is it needed?
CSP adds one extra layer of safeguard against the javascript injection attack. This header does not act like a fail-safe solution for the these kind of attacks but it helps making it more difficult for an attacker to inject the malicious content and steal the data.
How CSP works?
With CSP you can define your own rule set that will whitelist the content to be shown on the web page. The web browser will verify the content against the rule set, that will block the injected content which is not defined in the ruleset (This will throw the exception in the browser console).
CSP has two configuration modes:
Blocking or Enforcing mode: In this mode, the injected code will be blocked and report will be sent to the report-uri.
Report only mode: In report only mode, injected content won’t be blocked but the report will be sent to report-uri.
CSP implementation:
Before starting the CSP implementation, One should have the list of all the trusted domains from where you want to load the content.
CSP Rule set can have following directives:
Value for each directive can be defined in multiple ways depending on the requirement. Sources are defined in the scheme (data:, https:), or ranging from hostname-only (example.com this matches only the host ruleset, now this can have any port, origin or scheme) to the full url (https://www.example.com:443, so this matches only https scheme with the host example.com and port 443). CSP ruleset also accepts the wildcards too such as *://*.example.com:* this would match all the subdomains of example.com.
The source list also accepts four keywords:
‘None’: This means no source is defined for that directive.
‘self’ : This would match to the current source, not the subdomains.
‘Unsafe-inline’: This will allow inline JavaScript or CSS.
‘Unsafe-eval’: This allows text-to-JavaScript mechanisms like eval.
The “nonce” directive: So now if any attacker wants to inject any malicious payload (<script>alert(XSS);</script>), browser will not know whether it is genuine inline script tag or inject one. CSP solves this problem by suppressing the inline script entirely. CSP does this by by allowing you to whitelist specific inline scripts using either a random nonce (number used once) or a hash.
Schema for using nonce will be <script nonce={some random hash}> //inline js </script>
<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>
//Some inline code.
</script>
Now, add the nonce to your script-src directive appended to the nonce- keyword.
Content-Security-Policy: script-src ‘nonce-EDNnf03nceIOfn39fn3e9h3sdfa’
But this random nonces should be regenerated for every page request and they must be unguessable.
Basic misconfigurations:
- Missing base uri
- Static nonce for inline script
- Adding * while specifying the source
- Unsafe-inline without nonce
- Missing object-src or default-src directive
CSP limits:
Unfortunately, CSP is not a one stop solution: it prevents your website from the consequences, but not from the attack itself!
Today almost all of web browsers do support CSP except some older versions of internet explorer
Summary:
Thanks to CSP, you can choose the content that are allowed on your webpage and those that will be blocked. All thanks to CSP, now you get a chance to choose the content to be shown on the webpage. It is, indeed a good way to ensure that a third-party provider would not start loading dozens of unexpected files in your web page!
