HTML Content Security Policy

 

In this post we will review the usage of a content security policy (aka CSP) which is one of the methods to prevent XSS attacks. I have already reviewed one of the XSS related attacks, in a previous post: MageCart attack.

What is CSP?

The CSP is a method to block access to resources from a web page. Using CSP we can specify the allowed list of domains from which we allow to load style-sheets (CSS), images, videos, and more.

Why Should We Use CSP?

We want to prevent leakage of private information out of our site to an attacker site. We assume that this could occur in case one of our site 3rd party integrated was attacked, and a javascript was injected into it to leak out our private information. See an example int the post: MageCart attack.

How Do We Use CSP?

To use CSP, we can add an HTML meta tag, or a HTTP header in the HTML response:

Example of a meta tag:

<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Example of a HTTP header:

"Content-Security-Policy": "default-src 'self';"

The recommended method to use is the HTTP header, since the HTML meta tag does not support all of the CSP features.

The CSP header value, contains the CSP policy, whose syntax is as follows:

(CONFIGURATION_NAME VALUE_NAME+;)+

For example:

default-src 'self'; style-src 'self' 'unsafe-inline';

Which CSP Policy Should We Use?

If we want the most security, the policy should block any access to any external resource, so we should use:

default-src 'self';

But this would cause our entire site to fail. Why?

Because any internal script loading will be blocked, for example, the following javascript:

<script>
  alert('Hello World!')
</script>

is blocked.

How can we allow our internal javascripts to run?

We can use hash and nonce to allow our scripts (see this for more details), but it requires many changes to our site source, and to the server side.

A less costly method is to allow all scripts to run. This is OK only if our only purpose is to prevent data leakage, and we do not intend to prevent malicious internal site actions. To do this, we use the unsafe-inline directive:

default-src 'self' 'unsafe-inline';

The last step is to whitelist the domains that we do allow to access from our site, for example:

default-src 'self' 'unsafe-inline' https://connect.facbook.net;

Using CSP Report

Activating CSP protection is the first step in our site protection. The next step is to monitor the CSP: which URLs were blocked?

CSP provides a simple method to report the blocked resources. However, the server side should be implemented our our own.

To enable CSP reporting, use the report-uri directive:

default-src 'self' 'unsafe-inline'; report-uri http://myreport.com;

This sends a JSON request per each blocked resource.

An example of such request is:

{
  "csp-report": {
    "blocked-uri": "https://www.ynet.co.il/images/og/logo/www.ynet.co.il.png",
    "disposition": "enforce",
    "document-uri": "http://localhost:3000/domains",
    "effective-directive": "img-src",
    "line-number": 37,
    "original-policy": "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' ;report-uri http://127.0.0.1:2121/report;",
    "referrer": "http://localhost:3000/domains",
    "script-sample": "",
    "source-file": "http://localhost:3000/domains",
    "status-code": 200,
    "violated-directive": "img-src"
  }
}

Final Note

We have reviewed the HTML CSP as a method to block data leakage.

However, some attacks might use a whitelisted domain to address his own account within this domain. This can be done, for example, using the Google analytics domain.