Cross-Site-Scripting: Sichere Lesezeichenmanager
Stellen Sie sich vor, Sie arbeiten von zu Hause und müssen auf etwas im Netzwerk Ihres Unternehmens zugreifen. Sie öffnen dieselbe VPN-Seite wie immer, melden sich wie gewohnt an und machen weiter. Die Webadresse gehört Ihrem Unternehmen, und die Seite ist Teil des Systems, das Ihr Arbeitgeber Ihnen zur Nutzung vorgegeben hat. Es gibt keinen offensichtlichen Grund, darüber nachzudenken, was im Hintergrund passiert.
Ein Produkt, das Unternehmen häufig für den VPN-Zugriff verwenden, ist GlobalProtect von Palo Alto Networks. Damit können Menschen von überall auf private Unternehmensnetzwerke zugreifen. Viele kennen VPNs als Werkzeuge für den privaten Gebrauch, GlobalProtect ist jedoch für Unternehmen gedacht. Beschäftigte melden sich über ihr Unternehmen an, und GlobalProtect verwendet ein Online-Portal, um die Verbindung zum Unternehmensnetzwerk zu konfigurieren.
2025 veröffentlichten Sicherheitsforscher eine Cross-Site-Scripting-Schwachstelle in diesem browserbasierten Teil von GlobalProtect. Um die Schwachstelle gegen jemanden einzusetzen, musste ein Angreifer zunächst einen präparierten Link zur echten VPN-Website erstellen. Der Link konnte neben der eigentlichen Adresse vom Angreifer kontrollierte Informationen enthalten. Websites verwenden denselben grundlegenden Mechanismus ganz normal, um etwa Suchbegriffe, Kennungen oder andere Werte von einer Seite zur nächsten zu übergeben.
Dieser präparierte Link muss trotzdem erst eine Person erreichen. Ein Angreifer würde typischerweise Phishing oder eine andere Form von Social Engineering verwenden, um jemanden zum Anklicken zu bewegen: zum Beispiel eine E-Mail, die scheinbar aus dem eigenen Unternehmen kommt (siehe: E-Mail-Spoofing), eine Nachricht über eine angeblich notwendige VPN-Einstellung, ein Support-Gespräch oder einen anderen glaubwürdigen Anlass für den Klick.
Wenn das Opfer den Link öffnet, kann es trotzdem auf der echten VPN-Website des Unternehmens landen. GlobalProtect liest Informationen aus der präparierten URL und fügt sie in die Seite ein, die an den Browser zurückgesendet wird. Dieses Verhalten ist an sich nichts Ungewöhnliches. Websites lesen ständig Werte aus Links und entscheiden damit, was sie anzeigen.
Der Fehler liegt darin, wie dieser Wert in die Seite eingefügt wird. Die vom Angreifer kontrollierten Informationen sollten gewöhnlicher Text bleiben, eine zu prüfende ID oder eine allgemeine Einstellung, also nichts Mächtigeres als etwas, das in ein Formularfeld eingegeben wurde. Wenn die Website den Wert jedoch so in die Seite einfügt, dass der Browser ihn als HTML interpretiert, können vom Angreifer gelieferte Zeichen aufhören, bloßer Text zu sein. Sie werden dann zu Anweisungen, die die Seite verändern und JavaScript ausführen können. Der präparierte Teil kam über den Link hinein und wurde von der vertrauenswürdigen Website selbst versehentlich von Daten zu Code erhoben.
Jira liefert ein weiteres Beispiel für dasselbe Problem auf einem anderen Weg. 2021 veröffentlichte Atlassian eine Schwachstelle, bei der vom Angreifer kontrollierte projektbezogene Daten gespeichert und zurückgelassen werden konnten. Öffnete ein Administrator später die betroffene Seite „Associated Projects“, konnte der Browser diesen gespeicherten Wert als ausführbaren Inhalt interpretieren.
Das ist gespeichertes XSS: Der Angreifer platziert den schädlichen Inhalt zuerst, die Website behält ihn, und jemand anderes löst ihn später allein dadurch aus, dass die Seite geladen wird, auf der er erscheint.
Es gibt noch weitere Formen von XSS, aber die Liste ist lang und die meisten Details sind nur für Entwickler relevant. In einer perfekten Welt verhindern Entwickler solche Angriffe von vornherein, doch in der Realität passieren Fehler. Nutzer sollten darauf achten, welche Links sie öffnen, und sich der Gefahr durch Phishing und Social Engineering bewusst sein.
Damit sind wir bei der Grundidee hinter Cross-Site-Scripting, meist kurz XSS genannt. Informationen, die gewöhnliche Daten bleiben sollten, dürfen innerhalb einer vertrauenswürdigen Website zu ausführbarem Code werden.
Browser versuchen normalerweise, Websites voneinander zu trennen. Eine Seite auf einer Website sollte nicht einfach private Informationen von einer anderen Website lesen oder deren angemeldeten Zugriff verwenden können. XSS umgeht diesen Schutz auf eine andere Weise: Die verwundbare Website selbst sorgt dafür, dass vom Angreifer kontrollierter Code als Teil ihrer eigenen Seite ausgeführt wird.
Sobald der Browser diesen Code als Teil der vertrauenswürdigen Seite ausführt, werden die Folgen sehr konkret. Er kann möglicherweise Informationen lesen, die bereits auf der Seite angezeigt werden, Formularfelder beobachten oder verändern, Schaltflächen und Links ersetzen, Informationen an andere Stellen senden und vieles mehr. Der Browser kann die angemeldete Sitzung des Nutzers automatisch an solche Anfragen anhängen. Dadurch kann der schädliche Code möglicherweise mit dem Konto des Nutzers handeln, ohne dessen Passwort zu kennen.
Wenn die Person, die den schädlichen Code auslöst, als Administrator angemeldet ist, kann der Code möglicherweise dieselbe Berechtigung nutzen. Je nachdem, was die Website erlaubt, könnte das bedeuten, das Kontopasswort zu ändern, einen API-Schlüssel oder Zugriffstoken zu erstellen oder einen weiteren Administrator hinzuzufügen. Der Angreifer muss das Administratorpasswort möglicherweise überhaupt nicht kennen, weil der Browser bereits angemeldet und für diese Aktionen autorisiert ist.
Ein XSS-Angriff muss nicht unbedingt bei der Website enden, auf der er begonnen hat. Der kompromittierte Dienst kann selbst mit anderen Systemen verbunden sein oder Informationen kontrollieren, die später anderswo geöffnet werden. Dadurch kann ein erfolgreicher XSS-Angriff zum Sprungbrett für einen weiteren Angriff werden.
Ein Lesezeichenmanager ist dafür ein besonders interessantes Beispiel, weil seine Aufgabe darin besteht, Links zu speichern und sie Menschen später wieder vorzulegen. Schädlicher Code mit Zugriff auf ein Lesezeichenkonto könnte gespeicherte Links ändern, neue hinzufügen, geteilte Collections verändern oder speziell konstruierte URLs platzieren, die Schwachstellen in anderen Diensten angreifen. Werden diese Links synchronisiert oder mit anderen geteilt, kann der Angreifer sogar einen neuen Verbreitungsweg erhalten. Die zweite Website bräuchte weiterhin eine eigene Schwachstelle, damit ein weiterer XSS-Angriff gelingt, doch ein kompromittierter Lesezeichenmanager könnte dem Angreifer einen vertrauenswürdigen Ort geben, von dem aus solche Angriffe vorbereitet und verteilt werden.
An diesem Punkt werden Lesezeichenmanager zu einem eigenen interessanten Sicherheitsfall. Ihre gesamte Aufgabe besteht darin, Links von Menschen anzunehmen, zu speichern, zu synchronisieren, zu importieren und manchmal mit anderen zu teilen. Eine Collections-Funktion geht noch einen Schritt weiter: Ein Link, der von einer Person erstellt oder kontrolliert wird, kann später im Browser einer anderen Person landen.
Das bedeutet, dass Links nicht immer wie langweilige Textzeichenfolgen behandelt werden können. Ein Lesezeichenmanager kann wie eine relativ einfache Anwendung wirken, aber sobald er nutzergesteuerte Links annimmt und zwischen Konten, Importen oder geteilten Collections bewegt, wird der Umgang mit URLs zu einer echten Sicherheitsgrenze. Kleine und neu entwickelte Lesezeichenmanager müssen darüber genauso ernsthaft nachdenken wie größere.
JavaScript-Lesezeichen machen diese Grenze besonders deutlich. Browser unterstützen sie schon seit langer Zeit. Statt ein gewöhnliches Ziel wie https://example.com zu speichern, speichert ein Bookmarklet JavaScript und führt es aus, wenn die Person das Lesezeichen bewusst öffnet. Das kann äußerst nützlich sein, um eine Seite zu verändern, Informationen zu extrahieren oder eine Automatisierung zu starten.
Auch das integrierte Lesezeichensystem eines Browsers wurde in der Vergangenheit ausgenutzt, allerdings meist über einen ganz anderen Mechanismus, häufig mit Malware. In diesem Fall kommt die Gefahr von Software, die bereits Zugriff auf den Browser erlangt hat. Ein webbasierter Lesezeichenmanager hat ein anderes Problem zu lösen, weil JavaScript oder präparierte Links über mehrere ansonsten legitime Wege eintreffen können. Kam der Inhalt vom Kontoinhaber? Wurde er importiert? Kam er aus einer geteilten Collection? Wurde er von einer nicht vertrauenswürdigen Website eingefügt?
Darüber haben wir bei WebCull viel nachgedacht. JavaScript-Lesezeichen einfach gar nicht zu unterstützen, ist eine einfache Sicherheitsentscheidung und war für lange Zeit eine sehr vernünftige. Bookmarklets sind aber auch wirklich nützlich. Ich verwende WebCull selbst zunehmend in Entwicklungs- und Automatisierungsabläufen, und kleine JavaScript-Stücke können eine äußerst leistungsfähige Möglichkeit sein, ein Lesezeichen mit einer Aktion zu verbinden.
Deshalb behandelt WebCull JavaScript-Lesezeichen nicht wie gewöhnliche Links, sondern legt sie hinter ein eigenes Sicherheitssystem. JavaScript in Ihren eigenen Lesezeichen ist zunächst deaktiviert. JavaScript aus öffentlichen Collections hat eine vollständig getrennte Berechtigung, die ebenfalls zunächst deaktiviert ist. Das Aktivieren der einen Berechtigung aktiviert die andere nicht.
Wenn eine dieser Berechtigungen deaktiviert ist und Sie bewusst ein JavaScript-Lesezeichen öffnen, hält WebCull an und gibt Ihnen eine Wahl. Sie können abbrechen, Einmal ausführen wählen, ohne die Berechtigung dauerhaft einzuschalten, oder diese JavaScript-Kategorie ausdrücklich für zukünftige bewusste Öffnungen erlauben. Wenn Sie die Berechtigung aktivieren, können spätere Lesezeichen derselben Vertrauenskategorie bei einem bewussten Öffnen ohne weitere Warnung ausgeführt werden. Das Aktivieren ist deshalb eine echte Sicherheitsentscheidung und keine kosmetische Einstellung.
JavaScript-Lesezeichen dürfen außerdem niemals automatisch geöffnet werden, selbst wenn die passende Berechtigung aktiviert wurde. In der WebCull-Web-App läuft ein erlaubtes Bookmarklet in der aktuellen WebCull-Seite. Genau deshalb betrachten wir diese Funktion als mächtig und kennzeichnen diese Einstellungen als Weniger sicher.
Die Grenze für öffentliche Collections ist noch wichtiger, weil der Code von jemand anderem stammen kann und ein Eigentümer oder Mitwirkender der Collection den gespeicherten Inhalt später möglicherweise verändern kann. Deshalb hat JavaScript aus öffentlichen Collections eine eigene Berechtigung, statt die Berechtigung von Lesezeichen zu übernehmen, die Sie selbst kontrollieren.
Darauf lohnt es sich auch zu achten, wenn Sie einen beliebigen Lesezeichenmanager oder ein Tool für Linksammlungen bewerten. Fragen Sie, was passiert, wenn jemand ein javascript:-Lesezeichen speichert. Fragen Sie, ob geteilte Links zu ausführbarem Code werden können, ob JavaScript automatisch geöffnet werden kann und ob Code von anderen Personen von Code getrennt wird, den Sie selbst gespeichert haben. Ein Tool, das private Informationen speichert und nutzergesteuerte Links annimmt, muss diese Grenzen als Teil seines Sicherheitsmodells behandeln und nicht als Randfall.
Für Menschen, die das Web nutzen, sind präparierte Links weiterhin die praktischere Warnung. Sie werden bewusst so konstruiert, dass sie eine Schwachstelle in einer echten Website ausnutzen, und häufig über Phishing oder anderes Social Engineering verbreitet, das den Klick normal erscheinen lassen soll. Die Gefahr besteht nicht darin, dass gewöhnliche Links grundsätzlich unsicher sind. Ein schädlicher Link kann auf eine echte Website zeigen und trotzdem vom Angreifer kontrollierte Informationen tragen, die dort eine Schwachstelle auslösen sollen. Wenn Sie aufgefordert werden, Code von jemandem einzufügen oder auszuführen, ist das ein sehr großes Warnsignal. Auch Links aus nicht vertrauenswürdigen Quellen sollten Sie besser nicht öffnen.
Wenn Sie glauben, einen präparierten Link geöffnet zu haben, verlassen Sie sich nicht darauf, dass die Seite verdächtig aussieht. Ein erfolgreicher XSS-Angriff kann vollständig unsichtbar sein, während im Hintergrund Code mit dem Zugriff ausgeführt wird, den Ihr Browser bereits besitzt. Wenn Sie Grund zu der Annahme haben, dass ein Link schädlich war, folgen Sie den Sicherheits- oder Kontowiederherstellungshinweisen des betreffenden Dienstes. Das Abmelden aktiver Sitzungen, das Prüfen kürzlicher Kontoaktivitäten und gegebenenfalls das Ändern möglicherweise offengelegter Zugangsdaten sind sinnvolle Vorsichtsmaßnahmen. Handelt es sich tatsächlich um eine XSS-Schwachstelle, kann nur der Betreiber der Website die Schwachstelle selbst beheben.
Die oben beschriebenen Schwachstellen in GlobalProtect und Jira wurden öffentlich bekannt gegeben. In den öffentlichen Berichten wurde keine bestätigte Ausnutzung in freier Wildbahn dokumentiert. Sie sind daher nützliche Beispiele dafür, wie solche Angriffe funktionieren können, und keine Berichte über bekannte Sicherheitsvorfälle. Das OWASP Cross Site Scripting Prevention Cheat Sheet bietet eine wesentlich tiefere technische Referenz für Menschen, die Websites entwickeln.
Wenn Sie JavaScript-Lesezeichen in WebCull verwenden, lesen Sie die Dokumentation zu JavaScript-Lesezeichen. Dort werden die getrennten Berechtigungen, die Option „Einmal ausführen“ und die Vertrauensprüfungen erklärt, die Sie vor dem Öffnen durchführen sollten.