Eine Webseite kann bei einem gewöhnlichen Besuch Code laden, den Angreifer kontrollieren. Ist der Browser oder eine andere Komponente verwundbar, kann dieser Code einen Exploit versuchen, ohne dass du eine Datei startest. Das ist ein möglicher Angriffspfad, nicht das Ergebnis jedes verdächtigen Seitenbesuchs. Ob er gelingt, hängt von der konkreten Schwachstelle und den Schutzfunktionen des Browsers ab.
«Drive-by-Download» wird oft weit gefasst. Auslieferung und Kompromittierung sind jedoch verschiedene Schritte. Eine Seite kann still einen Browser-Exploit versuchen oder jemanden dazu bringen, einen Download, eine Benachrichtigung oder ein Installationsprogramm zu bestätigen. Laut MITREs Beschreibung von Drive-by-Kompromittierung ist bei manchen Varianten eine Nutzerhandlung nötig. Dieser Artikel behandelt Angriffe, bei denen ein Seitenbesuch ausreichen kann, wenn dabei eine verwundbare Stelle erreicht wird.
Warum ein Klick nicht immer nötig ist
Beim normalen Surfen kann eine Seite Skripte, Bilder, Schriften und Medien laden. Je nach Browser-Einstellungen und Seite können Skripte APIs für Grafik, Medien und WebAssembly verwenden. Bei der Verarbeitung dieser Inhalte kann eine Schwachstelle erreicht werden, auch wenn du keinen Anhang anklickst oder keine neue Berechtigung erteilst.
Ein Exploit braucht einen bestimmten Fehler und einen Auslöser, der ihn erreicht. Mögliche Ziele sind die JavaScript-Engine, Rendering-Code und Medienverarbeitung. Das blosse Laden einer Seite gibt ihrem Skript keine Systemrechte. Ein erfolgreicher Exploit kann stattdessen über einen Browserfehler Code im betroffenen Prozess ausführen, weiterhin begrenzt durch Sandbox und andere Schutzmassnahmen.
Moderne Browser trennen Websites und beschränken Renderer-Prozesse, wie die Dokumentation zu Chromes Site Isolation erklärt. Ein kompromittierter Renderer bedeutet nicht automatisch vollen Zugriff auf das Gerät. Angreifer benötigen möglicherweise einen weiteren Fehler, um die Sandbox zu verlassen oder mehr Rechte zu erhalten. Die Analyse einer Watering-Hole-Kampagne von 2024 durch Google dokumentiert einen Chrome-Renderer-Fehler in Kombination mit einem Sandbox-Ausbruch. Die Kette zielte auf bestimmte ungepatchte Android-Versionen, nicht auf alle Besucher.
Wo moderne Exploits zuschlagen
JavaScript-Engines. Engines wie V8 und SpiderMonkey enthalten Compiler und eine komplexe Speicherverwaltung. Ein Fehler kann unbeabsichtigtes Verhalten innerhalb eines Browserprozesses ermöglichen. Dieser Prozess wird normalerweise durch die Browser-Sandbox beschränkt; Engine-Code läuft nicht einfach mit uneingeschränkten Systemrechten.
Grafikfunktionen. WebGL und WebGPU stellen Grafikfunktionen über vom Browser kontrollierte APIs bereit. Browser- und Treiber-Implementierungen können Fehler enthalten. Shader gelangen aber nicht ungeprüft an die Hardware, und ein Grafikfehler beweist für sich allein keinen Sandbox-Ausbruch.
Medien- und Bildverarbeitung. Browser dekodieren komplexe Dateien aus nicht vertrauenswürdigen Seiten. Ein Fehler im Decoder kann ausnutzbar sein; seine Folgen hängen vom konkreten Fehler und vom Prozess ab, der die Datei verarbeitet. Die Sandboxes von Browser und Betriebssystem können den Schaden begrenzen. Ein Vorfall in einer Messaging-App ist kein Beleg für einen Browser-Exploit.
WebAssembly und Worker. Damit können Websites Code in eigenen Ausführungskontexten ausführen, weiterhin innerhalb der Browser-Regeln. Ihre blosse Verwendung ist kein Exploit. Fehler in einer Implementierung oder verwandten Browserkomponenten können Angreifern dennoch einen weiteren Weg eröffnen.
Wie die Seite auf deinen Bildschirm kommt
Der von Angreifern kontrollierte Inhalt muss den Browser erst erreichen. MITRE nennt schädliche Werbung, kompromittierte Websites, veränderte Ressourcen von Drittanbietern und eingeschleuste Skripte oder Frames als mögliche Wege. Wie häufig sie vorkommen, hängt von der Kampagne ab. Kein einzelner Weg dominiert alle Drive-by-Angriffe.
Bei Malvertising gelangt schädlicher Inhalt in einen Werbeplatz. Bei einem Watering-Hole-Angriff wird eine Website kompromittiert, die eine bestimmte Zielgruppe besucht. Beides bedeutet nicht, dass jeder Besucher erfolgreich kompromittiert wird: Die Seite kann zuerst Gerät und Browser prüfen, und manchmal ist eine weitere Handlung nötig. Den Weg über Werbung erklärt unser Leitfaden zu Malvertising.
In einem dokumentierten Fall von 2024 luden kompromittierte mongolische Regierungsseiten einen versteckten Frame mit Inhalt der Angreifer. Der Bericht der Threat Analysis Group von Google beschreibt verschiedene Exploit-Ketten für ausgewählte Besucher mit verwundbaren iOS- oder Android-Versionen. Für die Schwachstellen gab es bereits Patches; angegriffen wurden Geräte, die diese noch nicht erhalten oder angewendet hatten. Der Fall zeigt, wie eine vertraute Seite als Auslieferungsweg dienen kann, nicht dass jeder Besuch einer kompromittierten Seite erfolgreich endet.
Das Zeitfenster zwischen Patch und Rollout
Ein veröffentlichter Fix schützt keinen Browser, auf dem noch eine betroffene Version läuft. Der Zeitpunkt hängt von Anbieter, Plattform, Geräteunterstützung und Update-Regeln ab. Feste Angaben in Stunden oder Wochen wären irreführend. Der Fall aus Googles Bericht von 2024 zeigt, dass bereits behobene Fehler für bestimmte ungepatchte Geräte weiter ausnutzbar waren.
Angreifer können eine bekannte Schwachstelle ausnutzen, nachdem ein Patch erschienen ist. Das wird manchmal «N-Day» genannt. Sie können auch einen Fehler nutzen, bevor es einen Patch gibt, einen «Zero-Day». Wie lange die Entwicklung eines funktionierenden Exploits dauert und wie lange Nutzer verwundbar bleiben, variiert stark. Halte deshalb Browser und Betriebssystem aktuell und prüfe, ob ein Update noch auf Anwendung wartet.
Automatische Downloads helfen, doch ein installiertes Update kann einen Neustart erfordern. Der Update-Leitfaden von Google Chrome erklärt, wie du einen ausstehenden Neustart erkennst. Verwaltete Geräte können den Einführungsregeln ihrer Organisation folgen. Prüfe daher die tatsächlich laufende Version, statt anzunehmen, ein heruntergeladenes Update sei bereits aktiv.
Eindämmung, nicht Vermeidung
Vorsichtiges Surfen verringert die Angriffsfläche. Auch eine vertraute Website kann aber kompromittierten Inhalt laden. Halte Browser aktuell, nutze ihre eingebauten Schutzfunktionen und erwäge, unerwünschte Skripte oder Werbung zu blockieren. Antiviren- oder Endgeräteschutz kann Schadcode oder verdächtiges Verhalten erkennen, allerdings nicht garantiert. Browser-Sandbox und Site Isolation setzen zusätzliche Grenzen, falls etwas schiefgeht.
Bei einem entfernten Browser wie Browser.lol läuft der Seitencode in einem Container statt in deinem lokalen Browser. Ein Exploit trifft so zuerst auf eine andere Umgebung, und die Session kann beendet werden, wenn sie nicht mehr gebraucht wird. Das beweist nicht, dass dein Gerät oder deine Konten sicher sind. Heruntergeladene Dateien, eingegebene Zugangsdaten, Zwischenablage, Dateiübertragungen und die Infrastruktur des Dienstes eröffnen weitere Wege. Halte lokale und entfernte Browser-Images aktuell und gehe mit Dateien vorsichtig um. Den Unterschied zwischen Patching und Zero-Days erklärt unser Leitfaden zu Zero-Day-Exploits.
Brauchst du für deine nächste Aufgabe eine isolierte Session?
Starte eine isolierte Session direkt im Web.
Session startenKeine Browserinstallation nötig • Funktionen je nach Plan
