The dangers from across browser-windows
Beim Durchsuchen des Webs versucht Ihr Browser, Sie bestmöglich zu schützen, aber manchmal scheitert er daran, wenn er nicht ordnungsgemäß von der Website angewiesen wird, die Sie besuchen. Einer der wichtigsten Sicherheitsmechanismen des Browsers ist die Same-Origin Policy [1][2][3] (SOP), die einschränkt, wie Skripte und Dokumente aus einer Ursprungsquelle mit Ressourcen und Dokumenten aus einer anderen Ursprungsquelle interagieren können. Dieser Standard-Schutz ist möglicherweise immer noch nicht ausreichend, um einen Angriff auf Benutzer Ihrer Webanwendung zu verhindern. In diesem Beitrag werden verschiedene Angriffe auf Browserfenster und deren Abwehr besprochen.
Angriffe auf Browser Fenster
Die grundlegende Idee hinter einem Angriff auf ein Fenster besteht darin, dass ein Angreifer, der seine eigene Website kontrolliert (im Beispiel eve.com), auf programmatische Weise Zugriff auf einen Handle zu einer Opfer-Website (alice.com) erhält. Dies kann auf viele Arten geschehen und wird durch die SOP nicht verhindert. Die Website des Angreifers kann möglicherweise keine Quellübergreifenden Inhalte lesen oder schreiben, ist jedoch dennoch berechtigt, eine begrenzte Anzahl von Aktionen durchzuführen.
Um zu veranschaulichen, was möglich ist, könnte der folgende Code auf einer Website des Angreifers enthalten sein:
// Dieser Code ist auf eve.com eingebettet
// Öffnet die seite „alice.com“ wo Bob eingelogged ist
w = window.open(“alice.com”, “_blank”)Nun kann der Angreifer folgende Operationen trotz SOP problemlos durchführen:
// Nachrichten an „alice.com“ senden
w.postMessage(“hello”, “*”)
// Frame zählen
console.log(w.length)
// Zu einer andere Seite navigieren
// Zu bemerken ist, dass das kleine L durch ein großes I ersetzt wurde
w.location = “//aIice.com”
Die Illustration beschreibt die generelle Idee solch eines Angriffs beziehungsweise was notwendig für einen der folgenden Angriffe ist:
Das übliche Ziel dieser Angriffe ist es Informationen eines Nutzers zu extrahieren oder Login Informationen zu phishen. Durch das Hintereinanderschalten mehrerer Angriffe, ist es einem Angreifer auch möglich gut geschützte Informationen abzugreifen, wie wir im folgenden Beispiel zeigen werden.
Beispiel 1: Chained XS Search
Bob ist der Administrator einer Website und überprüft Berichte über Probleme mit der von ihm verwalteten Website. Zusätzlich gibt es eine administrative Oberfläche, auf die Bob von seinem lokalen Netzwerk aus zugreifen kann. Bobs administrative Oberfläche verfügt über ein Abfrage-basiertes Suchsystem, mit dem er Benutzernamen und Passwörter abfragen kann. Dieses System gibt eine Seite mit Frames für jedes Ergebnis zurück.
Eve entdeckt eine gespeicherte XSS-Schwachstelle auf Bobs Website, die es ihr ermöglicht, beliebigen Javascript-Code auf einer Seite auf Bobs Website einzufügen, der ausgeführt wird, sobald jemand diese Seite öffnet. Sie bereitet sorgfältig einen bösartigen Javascript-Schnipsel vor und fügt ihn in die Website ein. Anschließend sendet sie Bob einen Link zu seiner eigenen Website und beschwert sich darüber, dass etwas nicht stimmt.
Bob öffnet den Link, ohne zu wissen, dass der bösartige Javascript-Code verborgene iframes der sicheren administrativen Suchoberfläche mit Abfragen für Benutzernamen/Passwort-Kombinationen öffnet. Dies kann auf viele Arten geschehen, aber hier ist es wichtig zu beachten, dass aufgrund der Ergebnisse in iframes, obwohl die sichere administrative Oberfläche sicher auf einer anderen Herkunft liegt, Bobs eigene Website gegen ihn verwendet wird und ermitteln kann, wie viele iframes auf dieser lokal gesicherten Website generiert werden, was es Eves Skript im Grunde ermöglicht, Anmeldeinformationen aufzulisten.
Der grundlegende Javascript-Code, um so etwas zu erreichen, könnte wie folgt aussehen:
var iframe = document.createElement(“iframe”);
iframe.name = “xleaks”;
document.body.appendChild(iframe);
var win = window.open(“secure.admin/search?pwd=LIKE “ + knownPart + guessedCharacter + “.%”, “xsleaks”);
if(win.length != 0) {
console.log(“Erratener Buchstabe ” + guessedCharacter);
// Erratenen Buchstaben zu Alice schicken und wiederholen
}
iframe.remove();Wenn Anmeldeinformationen gefunden wurden, werden sie vom bösartigen Javascript-Schnipsel an Eve weitergesendet.
Es ist wichtig zu beachten, dass die SOP-Schwachstelle (Same-Origin Policy) ausgenutzt werden kann, ohne dass die XSS-Schwachstelle benötigt wird. Die XSS-Schwachstelle wird in diesem Beispiel nur hinzugefügt, um zu zeigen, wie Schwachstellen miteinander verknüpft werden können, um einen schwerwiegenderen Angriff zu erstellen.
Beispiel 2: Tabnabbing
Bob navigiert auf seiner Lieblings-Social-Media-Seite „toebook.com“ und sieht eine Anzeige für etwas, das er immer haben wollte, und beschließt, darauf zu klicken. Die Webseite sieht normal aus und beschreibt seinen Artikel der Wahl. Bob nimmt sich Zeit und inspiziert die Beschreibung sorgfältig, aber am Ende entscheidet er, dass er es nicht wirklich mag. Er schließt die Registerkarte des Geschäfts und kehrt zu „toebook.com“ zurück, nur um herauszufinden, dass er bei toebook ausgeloggt wurde! Begierig darauf, weiter zu surfen, gibt er seine Anmeldeinformationen ein und fährt mit der Social-Media-Seite fort. Was er nicht weiß, ist, dass er gerade von „t0ebook.com“ gephished wurde.
Die Social-Media-Seite öffnet normalerweise Anzeigen mit Javascript:
window.open(adsite, target=”_blank”)Während seines Aufenthalts auf der Seite von Eves Geschäft hat ihn bösartiger Javascript-Code in eine Tabnabbing-Falle gelockt und den ursprünglichen Tab von „toebook.com“ auf „t0ebook.com“ navigiert, eine Kopie des Login-Formulars von „toebook“, das die Anmeldeinformationen, die in das Login-Formular eingegeben werden, direkt an Eve sendet und den Benutzer auf die echte „toebook.com“ umleitet.
// Navigiert den ursprünglichen toebook.com Browsertab zu einer Kope des Login-Formulars das genau wie das echte aussieht
window.opener.location.replace(“https://t0ebook.com”)
Die Verbindung trennen
Das Hauptproblem, das solche Angriffe ermöglicht, besteht darin, dass ein Angreifer eine Referenz zu einem anderen Browserfenster erhalten kann. Obwohl der bösartige Akteur durch die SOP eingeschränkt ist, was er mit dieser Fensterreferenz tun kann, werden nicht alle Möglichkeiten blockiert, was kreative Angriffe ermöglicht.
Insbesondere können, wie wir in den Beispielen gezeigt haben, Angriffe, die die Lücken in der SOP ausnutzen, mit anderen Exploits kombiniert werden, um auch durch sehr verteidigte Setups zu dringen und sensible Informationen abzurufen.
Um solche Probleme zu lösen, kann der Browser angewiesen werden, von einem Webserver eine Website in einem isolierten Fenster darzustellen, wodurch es anderen Websites nicht mehr möglich ist, eine Referenz darauf zu erhalten. Dies kann erreicht werden, indem beim Bereitstellen einer Webanwendung durch den Webserver das Cross-Origin-Opener-Policy (COOP)[8] in die Antwort-HTTP(S)-Header eingefügt wird.
Die COOP funktioniert wie folgt:
- Wenn sie auf „same-origin“ eingestellt ist und die Ursprünge von zwei Seiten übereinstimmen, können sie miteinander interagieren, wie wir beschrieben haben.
- Wenn das COOP des Öffners auf „same-origin-allow-popups“ gesetzt ist und das COOP des Empfängers auf dem Standardwert „unsafe-none“ gesetzt ist, können die Seiten miteinander interagieren.
- Wenn eine der Seiten COOP setzt, wird der Browser für jede Seite mit COOP eine neue Kontextgruppe erstellen und somit die Verbindung zwischen den Seiten trennen.
Wenn wir nun versuchen, unseren Tabnabbing-Angriff von zuvor auszuführen, indem wir versuchen, zur Phishing-Website zu navigieren, werden wir aufgrund des auf „toebook.com“ festgelegten COOP auf „same-origin“ schnell mit einem TypeError: window.opener is null abgewiesen.
Fazit
Wie wir gesehen haben, kann es so einfach sein, geeignete Header zu setzen, um sich gegen sehr bösartige Versuche zu schützen, Angriffe gegen Ihre Webanwendung aus verschiedenen Browserfenstern zu starten, obwohl dies aufgrund der SOP nicht möglich sein sollte. Der entscheidende Teil hierbei ist zu wissen, dass diese Header existieren und Browser anweisen können, Ihre Webanwendung zu isolieren und Benutzern den Schutz zu bieten, den sie verdienen.
Zusätzlich gibt es Header, die in Verbindung mit COOP verwendet werden können, wie z.B. die Cross-Origin-Embedder-Policy (COEP)[9] und Cross-Origin-Resource-Policy (CORP)[10], die es sich lohnt, zu prüfen, um Ihre Webanwendung weiter zu isolieren und sich gegen Angriffe welche die Spectre Schwachstelle[11] nutzen zu verteidigen.
[1] https://web.dev/same-origin-policy/
[2] https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
[3] https://appsecmonkey.com/blog/same-origin-policy
[4] https://xsleaks.dev/docs/attacks/xs-search/
[5] https://xsleaks.dev/
[6] https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#tabnabbing
[7] https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html
[8] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
[9] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy
[10] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy
[11] https://web.dev/why-coop-coep/
[12] https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html
[13] https://leaky.page/