XS-Leaks: Was sie sind und wie Sie sie vermeiden

Cross-Site-Leaks (XS-Leaks) sind eine Klasse von Web-Sicherheitslücken, über die Angreifer sensible Informationen aus der Browsersitzung eines Nutzers auf anderen Websites oder in anderen Web-Apps erlangen können. Moderne Webanwendungen teilen Daten über verschiedene Funktionen und APIs – Angreifer können diese Funktionalität ausnutzen, um auf solche Nutzerdaten zuzugreifen.

Letztlich führen XS-Leaks zur Offenlegung sensibler Informationen, die böswillige Akteure für zahlreiche illegale Zwecke nutzen können, etwa um sich unbefugten Zugriff auf vertrauliche Systeme oder Datenbanken zu verschaffen.

In diesem Artikel erfahren Sie mehr darüber, was XS-Leaks sind und wie sie entstehen. Anschließend sehen wir uns einige praktische Beispiele zur Vermeidung an.

Wie XS-Leaks entstehen

Moderne Webanwendungen sind äußerst komplex und umfassen mehrere Domains mit unterschiedlichen Vertrauensstufen. Damit das Nutzungserlebnis im Browser reibungslos bleibt, müssen Websites daher Informationen austauschen können. Entwickler haben zwar dafür gesorgt, dass diese Kommunikation relativ sicher ist, doch die Funktionen von Websites und Browsern weisen bestimmte inhärente Schwachstellen auf.

XS-Leaks entstehen, wenn Angreifer diese Schwachstellen ausnutzen, um sich unbefugten Zugriff auf private Nutzerdaten zu verschaffen. Indem sie verschiedene Webfunktionen – etwa Cookies, JavaScript-APIs, CSS-Stylesheets und HTML-Elemente – manipulieren und Seitenkanäle sowie anwendungsspezifische Schwachstellen ausnutzen, können Angreifer sensible Informationen von anderen Websites extrahieren, die ein Nutzer besucht. Zudem erfolgen diese Angriffe unbemerkt und ohne Wissen oder Zustimmung des Nutzers.

Welche Arten von XS-Leaks gibt es?

Angreifer können verschiedene Arten von XS-Leaks nutzen. Sehen wir uns einige davon an.

Timing-Angriffe

Bei einem Timing-Angriff versucht ein böswilliger Akteur, sensible Systeminformationen zu sammeln, indem er misst, wie lange verschiedene Vorgänge dauern. Der Angreifer sendet speziell präparierte Skripte an die Zielwebsite, um API-Aufrufe oder AJAX-Anfragen auszuführen oder Ressourcenanfragen auszulösen, für die Cross-Origin Resource Sharing (CORS) erforderlich ist. Anschließend wertet er die Dauer dieser Vorgänge aus, um Rückschlüsse darauf zu ziehen, wie die Website funktioniert oder Daten verarbeitet.

Ein Angreifer könnte beispielsweise beobachten, wie lange die serverseitige Validierung benötigt, um verschiedene Eingaben – etwa Kombinationen aus Benutzernamen und Passwörtern – über Cross-Origin-Anfragen zu verarbeiten. Anhand auffälliger Zeitunterschiede kann er dann beurteilen, ob ein Anmeldeversuch erfolgreich war, oder herausfinden, ob ein Nutzer Administrator oder regulärer Nutzer ist. Diese Informationen dienen dem Angreifer als Grundlage für die nächsten Schritte.

Frame-Zählung

Bei Frame-Zählangriffen erstellt der Angreifer mehrere verschachtelte iFrames, die auf verschiedene URLs einer Zielwebsite verweisen. Dann nutzt er die CORS-Funktionalität der Website, um festzustellen, wie viele Frames der Browser des Nutzers beim Aufrufen der Ziel-URLs lädt.

Stellen Sie sich einen Angreifer vor, der mehrere verschachtelte iFrames für geschützte Bereiche einer Website erstellt, etwa für die Kontoeinstellungen und den Bestellverlauf. Besucht ein Nutzer eine Seite mit den eingeschleusten iFrames des Angreifers, zählt dieser, welche Frames erfolgreich geladen werden und welche nicht. Anhand dieser Informationen kann er auf Kontobeschränkungen schließen – etwa auf erforderliche Authentifizierungen oder Mitgliedschaftsstufen – und so herausfinden, ob ein bestimmter Nutzer Zugriffsrechte oder frühere Interaktionen mit bestimmten Bereichen der Zielwebsite hat.

Cache-Abfragen

Bei Cache-Abfragen werden Browser-Caches ausgenutzt, in denen Webinhalte lokal auf den Geräten der Nutzer gespeichert werden. Für diesen Angriff erstellt der Angreifer eine bösartige Website, die bestimmte Ressourcen – etwa Bilder oder Skripte – von der Zielwebsite anfordert. Die angeforderten Ressourcen weisen besondere Merkmale auf, beispielsweise ungewöhnliche Dateigrößen oder Ladezeiten.

Der Angreifer misst, wie schnell die Ressourcen geladen werden, wenn ein Nutzer seine bösartige Website besucht – entweder direkt vom Zielserver oder aus dem Cache des Nutzerbrowsers. Anhand dieser Informationen kann er ableiten, ob sich die Ressourcen bereits im lokalen Browser-Cache des Nutzers befanden.

Wie bei der Frame-Zählung können die durch Cache-Abfragen gewonnenen Informationen dazu dienen, Phishing-Kampagnen gezielt anzupassen, Verbindungen zwischen separaten Konten aufzudecken, die bei mehreren Onlinediensten und Plattformen verwendet werden, und komplexere Angriffe zu koordinieren.

Welche Mechanismen stecken hinter XS-Leaks?

Bei XS-Leak-Angriffen werden inhärente Browserfunktionen manipuliert und indirekte Beobachtungstechniken eingesetzt, um sich unbefugten Zugriff auf sensible Daten zu verschaffen. Zu den Mechanismen, die den Erfolg eines XS-Leak-Angriffs ermöglichen, gehören:

• Browserfunktionen ausnutzen – Angreifer verwenden Browserfunktionen wie Prefetching, Prerendering und verschiedene APIs wie Fetch oder WebSockets. Durch Manipulation oder Kombination dieser Funktionen mit anderen Techniken, etwa Cache-Abfragen, können sie sensible Informationen von Nutzern extrahieren, ohne die Same-Origin-Policy (SOP) direkt zu verletzen.

• Seitenkanäle – Dabei handelt es sich um indirekte Wege, über die Angreifer sensible Informationen sammeln. Aufgrund der Sicherheitsbeschränkungen durch SOPs in Webanwendungen greifen sie nicht direkt auf die Daten zu, sondern beobachten beispielsweise Abweichungen bei der Rendering-Zeit oder beim Laden von Ressourcen in den Browsern der Nutzer.

• Cross-Origin-Kommunikation – Angreifer können auch Kommunikationsmethoden zwischen verschiedenen Origins ins Visier nehmen, etwa die postMessage-API und Web Workers. Anschließend können sie Nachrichten zwischen verschiedenen Origins abfangen oder manipulieren, die in iFrames auf einer einzelnen Seite eingebettet sind.

Schwachstellen, die bei XS-Leaks ausgenutzt werden

Mithilfe der oben beschriebenen Mechanismen können Angreifer auf sensible Informationen zugreifen, ohne Sicherheitsrichtlinien wie CORS und SOP direkt zu verletzen, die auf den meisten modernen Websites eingesetzt werden.

Diese Maßnahmen verhindern jedoch nicht, dass XS-Leaks auftreten. Angreifer können Seitenkanäle nutzen, um SOP-Schutzmechanismen zu umgehen, CORS-Fehlkonfigurationen ausnutzen und weitere Schwachstellen zu einem koordinierten Angriff kombinieren.

CORS und SOP regeln, wie Ressourcen verschiedener Origins miteinander interagieren. Die SOP verhindert, dass Webseiten auf Daten oder Inhalte zugreifen, die von einer anderen Domain geladen wurden, und stellt so sicher, dass Skripte im Kontext ihrer Origin ausgeführt werden. CORS erweitert diese Richtlinie, indem bestimmte Cross-Origin-Anfragen zugelassen werden, sofern der Server den Zugriff auf seine Ressourcen ausdrücklich über HTTP-Header erlaubt. Theoretisch ermöglicht diese Kombination eine sichere Kommunikation zwischen Websites und verhindert bösartige domainübergreifende Interaktionen wie Cross-Site-Request-Forgery-Angriffe (CSRF) und unbefugten Datenzugriff.

Da XS-Leaks jedoch Seitenkanäle und die indirekte Offenlegung von Daten ausnutzen, können Angreifer die SOP umgehen, indem sie sensible Informationen von einer anderen Origin ableiten. Ebenso kann eine fehlerhafte oder unsichere Implementierung von CORS in einer Webanwendung zu Informationslecks führen.

Eine weitere Möglichkeit für böswillige Akteure, XS-Leak-Techniken einzusetzen, ist die Verkettung von Schwachstellenausnutzungen. Cross-Site-Scripting (XSS) lässt sich gut mit XS-Leaks kombinieren. Hat ein Angreifer eine XSS-Schwachstelle ausgenutzt, kann er anschließend versuchen, über verschiedene Browserfunktionen oder APIs, die Seitenkanalinformationen offenlegen, XS-Leaks auszulösen.

Ein böswilliger Akteur kann diese beiden Angriffsvektoren kombinieren, um sensible Daten aus der kompromittierten Domain zu erlangen und zusätzliche Erkenntnisse über Cross-Origin-Zugriffe zu gewinnen, ohne die SOP direkt zu verletzen.

Welche Folgen haben XS-Leaks?

XS-Leak-Angriffe können schwerwiegende Folgen haben, etwa die Offenlegung sensibler Informationen: Ein Angreifer kann auf vertrauliche Daten wie persönliche Angaben oder Finanzinformationen zugreifen. Anschließend kann er private Nutzerinformationen ohne deren Zustimmung manipulieren, stehlen oder missbrauchen.

Eine weitere mögliche Folge von XS-Leak-Angriffen ist Session-Hijacking. Dabei übernimmt ein Angreifer die Kontrolle über die aktive Sitzung eines Nutzers und kann in dessen Namen unbefugte Änderungen vornehmen. Diese Folgen gefährden die Privatsphäre und Sicherheit einzelner Nutzer und untergraben das Vertrauen in Onlineplattformen und -dienste.

Wichtig ist, dass XS-Leaks oft als Teil umfassenderer Angriffstechniken oder Schwachstellen betrachtet werden. Bei aufsehenerregenden Datenlecks, über die in den Medien breit berichtet wird, müssen XS-Leaks nicht zwangsläufig die zentrale Angriffsmethode sein. Böswillige Angreifer können XS-Leaks jedoch für stärker koordinierte Angriffe nutzen.

Best Practices zur Verringerung des Risikos von XS-Leak-Angriffen

Es gibt zwar keine Universallösung zur Verhinderung von XS-Leaks, doch Sie können die damit verbundenen Risiken deutlich verringern. In den folgenden Abschnitten stellen wir Best Practices zur Eindämmung von XS-Leaks vor und zeigen praktisch, wie Sie sie umsetzen.

Eine Content Security Policy verwenden

Implementieren Sie eine strenge Content Security Policy (CSP), um die Quellen von Inhalten einzuschränken, die der Browser auf Ihren Websites laden darf. So verringern Sie potenzielle Informationslecks, die entstehen, wenn Angreifer XSS oder andere Injection-Schwachstellen ausnutzen.

Sie können CSP mithilfe eines HTTP-Antwort-Headers namens Content-Security-Policy implementieren, wie unten gezeigt:

1<meta http-equiv="Content-Security-Policy" content="
2    default-src 'none';
3    script-src 'self' https://ajax.googleapis.com;
4    img-src 'self';
5    style-src 'self' https://fonts.googleapis.com;
6    font-src 'self' https://fonts.gstatic.com;">

In diesem Beispiel dürfen keine externen Ressourcen geladen werden (default-src), sofern sie nicht ausdrücklich durch andere Direktiven festgelegt sind. Skripte (script-src), Bilder (img-src), Stylesheets (style-src) und Schriftarten (font-src) dürfen nur von unserer Domain (self) oder von Google API (googleapis.com) geladen werden.

Eine klar definierte CSP hilft, unbefugte Cross-Origin-Anfragen und die Ausführung von Inline-Code zu verhindern, indem sie zulässige Quellen für Inhalte wie Skripte, Bilder, Stylesheets und mehr festlegt.

Das SameSite-Attribut für Cookies durchsetzen

Das Attribut SameSite in einem Cookie legt fest, ob der Browser das Cookie in externen Anfragen mitsenden soll. In JavaScript sieht das beispielsweise so aus:

document.cookie = "username=JohnDoe; path=/; Secure; SameSite=Strict";

Das Cookie username enthält den Wert JohnDoe, und der Pfad / bedeutet, dass das Cookie auf allen Seiten unserer Domain verfügbar ist. Das Schlüsselwort Secure stellt sicher, dass das Cookie nur über HTTPS-Verbindungen übertragen wird. Schließlich setzen wir das Attribut SameSite auf einen der folgenden Werte:

• None – Das Cookie wird mitgesendet, wenn die Übertragung über einen sicheren HTTPS-Kanal erfolgt.

• Lax – Dies ist das Standardverhalten bei Chromium-basierten Browsern. Das Cookie wird bei GET-Anfragen mitgesendet, die durch eine Navigation auf oberster Ebene ausgelöst werden.

• Strict – Das Cookie wird niemals außerhalb unserer Domain mitgesendet.

Wenn Sie das Attribut SameSite für Cookies auf Strict setzen, werden sie bei Cross-Site-Anfragen nicht mitgesendet. Dadurch lassen sich CSRF- und einige XS-Leak-Angriffe eindämmen, etwa solche, bei denen Zeitmessungen zum Einsatz kommen.

Sensible Daten in URLs möglichst vermeiden

Sensible Daten möglichst nicht in URLs zu verwenden, ist eine wichtige Best Practice der Cybersicherheit. Sensible Daten wie Zugangsdaten oder personenbezogene Daten (PII) sollten niemals in URLs enthalten sein, da Angreifer sie leicht über den Browserverlauf, Serverprotokolle, Referrer-Header und nicht bereinigte geteilte Links abrufen können.

Sensible Daten lassen sich unter anderem wie folgt aus URLs heraushalten:

• POST-Anfragen über HTTPS verwenden, statt sensible Daten in URLs aufzunehmen

• Sitzungstoken verwenden, statt Zugangsdaten oder personenbezogene Daten direkt zu übermitteln

Rate-Limiting implementieren

Eine weitere Best Practice ist Rate-Limiting für sensible Endpunkte, insbesondere für solche, die anfällig für Enumeration- oder Brute-Force-Angriffe sind. Dadurch wird die Anzahl der Anfragen begrenzt, die ein Angreifer innerhalb eines bestimmten Zeitraums stellen kann, und die Wirksamkeit von XS-Leak-Angriffen nimmt ab. Für die Implementierung von Rate-Limiting stehen in verschiedenen Programmiersprachen und Web-Frameworks Bibliotheken oder Middleware-Lösungen zur Verfügung.

In Node.js mit Express benötigen Sie beispielsweise das Middleware-Paket express-rate-limit, das Sie mit dem Befehl npm install express-rate-limit installieren. Anschließend können Sie den serverseitigen Rate Limiter wie folgt einrichten:

1const express = require('express');
2const app = express();
3const RateLimit = require('express-rate-limit');
4
5// Create a new limiter allowing 100 requests per hour from each IP address.
6// You can adjust these numbers based on desired limits.
7const apiLimiter = new RateLimit({
8  windowMs: 60 * 60 * 1000,
9    max: 100,
10    message: "Too many requests from this IP. Please try again after an hour."
11});
12
13app.use('/api/sensitive-endpoint', apiLimiter); // Apply limit to sensitive API endpoint.
14
15// Your other routes and middleware configurations here
16
17app.listen(3000, () => {
18 console.log("Server started on port ",3000);
19});

Beachten Sie, dass diese Maßnahme besonders wirksam ist, wenn sie mit anderen kombiniert wird. Sie stärkt Ihr Sicherheitsprofil gegen XS-Leak-Angriffe, bei denen zahlreiche Anfragen an Ihren Server gestellt werden, um Informationen zu sammeln.

CORS-Konfigurationen korrekt einrichten

Stellen Sie sicher, dass Ihre Anwendung korrekt konfigurierte CORS-Einstellungen verwendet. So verhindern Sie, dass nicht autorisierte Domains Cross-Origin-Anfragen stellen und auf geschützte Ressourcen zugreifen. Konfigurieren Sie CORS-Header wie Access-Control-Allow-Origin so, dass nur vertrauenswürdige Ursprünge Cross-Origin-Anfragen senden können. Vermeiden Sie dabei unnötige Platzhalter (*) in Listen erlaubter Ursprünge.

Wenn ein Server in seinem Header Access-Control-Allow-Origin beliebige Ursprünge (*) zulässt oder dynamisch generierte Ursprünge ohne ordnungsgemäße Validierung von Benutzereingaben (z. B. einem Referrer) verwendet, können Angreifer dies ausnutzen, indem sie von bösartigen Websites aus Cross-Origin-Anfragen stellen.

Integrationen wie Snyk Code nutzen

Snyk Code hilft Ihnen, Sicherheitslücken zu erkennen und zu beheben, indem es in Ihren Entwicklungsworkflow integriert wird. Dabei scannt es Abhängigkeiten, benachrichtigt Sie über Sicherheitslücken, schlägt Korrekturen vor und wendet sie an und überwacht Ihr Projekt kontinuierlich auf Sicherheitsprobleme. Wenn Sie beispielsweise eine Node.js-Anwendung mit Express.js erstellen, unterstützt Sie Snyk Code mit einem einfachen Verfahren dabei, sich vor Sicherheitslücken zu schützen, die durch fehlende Security-Header entstehen:

1. Abhängigkeiten scannen — Nachdem Sie Snyk in Ihr Projekt integriert haben, können Sie die Abhängigkeiten des Projekts scannen und Ihre Pakete auf bekannte Sicherheitslücken prüfen.

2. Problem erkennen — Fehlen Security-Header, erkennt Snyk Code diese Sicherheitslücke und benachrichtigt Sie. Snyk kann beispielsweise feststellen, dass Ihrer Anwendung der CSP-Header fehlt, der zum Schutz vor XSS-Angriffen beitragen kann.

3. Korrektur vorschlagen — Snyk empfiehlt eine Korrektur für die erkannte Sicherheitslücke. Bei fehlenden Security-Headern kann Snyk vorschlagen, das helmet middleware zu Ihrer Express.js-Anwendung hinzuzufügen. Helmet ist ein beliebtes Paket, das Ihrer Anwendung standardmäßig verschiedene Security-Header hinzufügt.

Snyk überwacht Ihr Projekt außerdem kontinuierlich auf neue Sicherheitslücken und Aktualisierungen bereits bekannter Sicherheitslücken. Bei weiteren Problemen erhalten Sie Benachrichtigungen. So behalten Sie die Sicherheit Ihres Projekts dauerhaft im Blick.

XS-Leaks verhindern 

Mit XS-Leaks können Angreifer sensible Informationen aus der Browsersitzung eines Benutzers auf einer anderen Website auslesen. Hacker nutzen dazu Browserfunktionen, Seitenkanäle und Cross-Origin-Kommunikation aus. Zu den gängigen XS-Leak-Techniken gehören Timing-Angriffe, Frame-Zählung und Cache-Abfragen.

Es gibt keine garantierte Methode, um XS-Leaks zu verhindern. Die in diesem Artikel beschriebenen Best Practices können das Risiko jedoch erheblich senken und sensible Informationen von Benutzern vor unbefugtem Zugriff oder Offenlegung schützen.