The Security in CSP: Note

This is another study notes or learning notes of the security headers after the first one “The study of the security headers — Learning notes”. This time, we can look into the CSP directives that are similar to the security headers many of them obsoleted.

Write CSP Policy

Writing a policy directive in CSP syntax is the following

Content-Security-Policy: policy

policy: is the one where we add the directive here with respective with the level of protection like ‘none’ or ‘self’.

The CSP policy will have the following

<host-source>

• http://*.example.com: Matches all attempts to load from any subdomain of example.com using the http: URL scheme.
• mail.example.com:443: Matches all attempts to access port 443 on mail.example.com.
• https://store.example.com Matches all attempt to access store.example.com using.https:
• *.example.com Matches all attempt to load from any subdomain of example.com using the current protocol.

<scheme-source >

• data: Allows data: URIs to be used as a content source.
• mediastream: Allows mediastream: URIs to be used as a content source.
• blob: Allows blob: URIs to be used as a content source.
• filesystem: Allows filesystem: URIs to be used as a content source.

Note: This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.

So, how it looks like after adding the policy with the directive

Content-Security-Policy: default-src 'self'; script-src https://example.com

Now what?

Let’s list out the directives which are alternative for the security headers

X-Frame-Options and Frame-Ancestors

The X-Frame-Options is a response header, whether a page of an application allowed to render a page in the frame — iFrame. The missing header in the response might cause to exploit the click jack vulnerability by a malicious user/attacker to load up the page in iFrame.

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://example.com/

The CSP directive for the same above-mentioned is like

Content-Security-Policy: frame-ancestors 'none'
Content-Security-Policy: frame-ancestors 'self'
Content-Security-Policy: frame-ancestors https://a.example.com 

Wait, we have to look into the frame-src now and how it works

A page /a with the following directive is and page /b is also with the directives respectively defined as below.

Page A

frame-src 'none';frame-ancestors 'self'

Page B

frame-src 'self';frame-ancestors 'none'

Page A can be framed by page B within an iframe tag but page B cannot be framed by page A as per the frame-src.

Page A doesn’t allow it from frame any subresource by adding the CSP “frame-src ‘none’ and page B does not allow it to be framed by any other pages by frame-ancestors ‘none’.

Note: Frame-Ancestor cannot be used in the meta page or tag, but it must be specified in the CSP header.

X-XSS Protection

The response header is a feature of the Safari, IE and Chrome browsers, and it will prevent the loading of the pop-up window when it detects the rXSS attacks.

When a malicious user or attacker tries to inject the reflective cross-site script payload into the application parameter, the header will prevent the page rendering.

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

Content-Security-Policy Without allowing unsafe-inlineis similar to the X-XSS-Protection in the CSP directive.

Example

Content-Security-Policy: script-src 'unsafe-inline'

Note: Please look into the more directives for a better understanding from the Mozilla developer site direct like connect-src, sandbox, etc.

Reference: https://developer.mozilla.org/ & https://content-security-policy.com/