Content Security Policy (CSP) Bypass
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unisciti al HackenProof Discord server 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 e inizia a collaborare con i migliori hacker oggi stesso!
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 della 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:
Implementato tramite meta tag:
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.
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 è:
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 mancano direttive di recupero specifiche.
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.)
*: 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:
'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.
Working payload: "/><script>alert(1);</script>
Questo non funziona, per maggiori informazioni controlla questo.
Payload funzionante:
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.
Payload funzionante:
Sembra che questo non funzioni più
Payload funzionanti:
Se puoi caricare un file JS, puoi eludere questo CSP:
Payload funzionante:
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).
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. Inoltre, nota che default-src non copre le azioni del modulo.
Per alcuni dei seguenti payload unsafe-eval non è nemmeno necessario.
Carica una versione vulnerabile di angular ed esegui JS arbitrario:
window (guarda questo post):Il post mostra che puoi caricare tutte le librerie da cdn.cloudflare.com (o 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.
Angular XSS da un nome di classe:
Secondo questo writeup CTF puoi abusare di https://www.google.com/recaptcha/ all'interno di un CSP per eseguire codice JS arbitrario bypassando il CSP:
More payloads from this writeup:
Il seguente URL reindirizza a example.com (da qui):
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.
Scenari come questo in cui script-src è impostato su self e un dominio particolare che è nella whitelist possono essere aggirati utilizzando JSONP. Gli endpoint JSONP consentono metodi di callback insicuri che permettono a un attaccante di eseguire XSS, payload funzionante:
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.
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. Alcuni di questi terzi sono:
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:
or
Dovresti essere in grado di esfiltrare dati, similmente a come è sempre stato fatto con Google Analytics/Google Tag Manager. In questo caso, segui questi passaggi generali:
Crea un account sviluppatore Facebook qui.
Crea una nuova app "Facebook Login" e seleziona "Sito web".
Vai su "Impostazioni -> Base" e ottieni il tuo "App ID".
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.
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).
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:
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 per ulteriori spiegazioni su altri abusi di terze parti.
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:
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 bypassate.
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
Se la direttiva base-uri è mancante, puoi abusarne per eseguire un dangling markup 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.
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:
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
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.
Payload funzionanti:
Altri endpoint di esecuzione arbitraria JSONP possono essere trovati qui (alcuni di essi sono stati eliminati o corretti)
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, se il reindirizzamento porta a un percorso diverso, può eludere le restrizioni originali.
Ecco un esempio:
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.
Leggi come qui.
'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):
From: 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/
La funzione importScripts dei service workers non è limitata dal CSP:
Ricerca: https://portswigger.net/research/bypassing-csp-with-policy-injection
Se un parametro inviato da te viene incollato all'interno della dichiarazione della politica, allora potresti alterare la politica in qualche modo che la renda inutile. Potresti consentire script 'unsafe-inline' con uno di questi bypass:
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
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
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 una flag verrà estratta, ogni volta che un carattere viene indovinato correttamente tramite SQLi la risposta richiede più tempo a causa della funzione sleep. Poi, sarai in grado di estrarre la flag:
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.
In questo writeup CTF, CSP viene bypassato iniettando all'interno di un iframe consentito un CSP più restrittivo che non consentiva di caricare un file JS specifico che, poi, tramite inquinamento del prototipo o clobbering del DOM permetteva di abusare di uno script diverso per caricare uno script arbitrario.
Puoi limitare un CSP di un Iframe con l'attributo csp:
In questo CTF writeup, è 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 essere disabilitati rimuovendo l'entry che consente il loro nonce e abilitando script inline specifici tramite sha:
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) verrà inviata al server da Content-Security-Policy-Report-Only.
Per un esempio controlla questo writeup CTF.
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 della CSP stessa per dedurre il sottodominio segreto. Questo metodo si basa su un algoritmo di ricerca binaria e sull'aggiustamento della 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 la CSP potrebbe essere configurata per facilitare questo metodo:
Monitorando quali richieste sono bloccate o consentite dal CSP, si può restringere i 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.
Unisciti al server HackenProof Discord 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 dell'hacking in rapida evoluzione attraverso notizie e approfondimenti in tempo reale
Ultimi annunci Rimani 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 stesso!
Secondo la ultima tecnica commentata in questo video, 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 attiverà.
PHP è noto per bufferizzare la risposta 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.
Da questo writeup sembra che fosse possibile bypassare una protezione CSP caricando una pagina di errore (potenzialmente senza CSP) e riscrivendo il suo contenuto.
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:
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 src=/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/
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.
Potresti semplicemente aggiornare la posizione per inviare al server dell'attaccante le informazioni segrete:
Puoi reindirizzare iniettando un meta tag (questo è solo un reindirizzamento, non farà leak di contenuto)
Per caricare le pagine più velocemente, i browser pre-risolveranno i nomi host in indirizzi IP e li memorizzeranno nella cache 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:
Un altro modo:
Per evitare che ciò accada, il server può inviare l'intestazione HTTP:
A quanto pare, questa tecnica non funziona nei browser headless (bot)
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:
Un'altra opzione:
https://csper.io/docs/generating-content-security-policy
Unisciti al Discord di HackenProof 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 e inizia a collaborare con i migliori hacker oggi stesso!
```html ```
Impara e pratica l'hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
