Der Entwickler öffnete einen Link aus einem Discord-Channel, in dem Kollegen über ein neues Build-Tool sprachen. Er klickte nichts an, tippte nichts ein, lud nichts herunter. Die Seite baute sich nicht sauber auf, irgendwas mit einer veralteten Schriftart. Fünf Minuten später meldete sein Laptop ungewöhnliche Prozessaktivität. In den paar hundert Millisekunden, in denen die Seite rendert hatte, war ein Speicherfehler im WebGL-Renderer ausgenutzt worden.
Drive-by-Downloads sind die heimtückischste Angriffsart im Browser. Sie verlangen keine Interaktion. Das Opfer öffnet die Seite, und der Exploit läuft schon. Was Anfang der 2000er über ActiveX-Komponenten lief, nutzt heute Lücken in JavaScript-Engines, WebGL, WebAssembly und Codecs. Moderne Browser sind robuster, dafür ist die Angriffsfläche deutlich gewachsen.
Warum kein Klick nötig ist
Der Browser ist kein simpler Seiten-Renderer. Er ist eine vollwertige Laufzeitumgebung: Jede geladene Seite darf JavaScript ausführen, Grafiken an deine GPU schicken, Video-Streams dekodieren und WebAssembly-Binaries lokal starten. Das alles passiert automatisch, sobald das HTML im Parser ankommt.
Ein Drive-by-Download greift genau in diese Pipeline. Ein Bug in der JavaScript-Engine, durch den ein Array-Index über seine Grenzen hinausläuft, eine Race Condition in der Canvas-API, ein fehlerhaft dekodierter Video-Frame, der einen Speicherüberlauf auslöst, das sind alles Einstiegspunkte. Der Browser führt den Exploit-Code aus, weil er zum Seiteninhalt gehört, nicht weil du irgendwas bestätigt hast.
Die Sandbox des Browsers fängt viele Versuche ab. Richtig gefährlich wird es bei verketteten Exploits: Ein Bug in der JavaScript-Engine liefert beliebigen Speicherzugriff, ein zweiter Bug bricht aus der Sandbox aus, ein dritter eskaliert die Rechte auf Systemebene. Solche Ketten sind für Angreifer teuer, landen aber zuverlässig in gross angelegten Kampagnen.
Wo moderne Exploits zuschlagen
JavaScript-JIT. Moderne Engines wie V8 und SpiderMonkey kompilieren oft genutzte Funktionen zur Laufzeit in Maschinencode. Fehler im JIT-Compiler erzeugen fehlerhaften Code, den der Browser mit vollen Rechten ausführt. Die meisten ausgenutzten Browser-Bugs der letzten Jahre kommen aus dieser Ecke.
WebGL und WebGPU. Shader landen ungefiltert auf deiner GPU. Grafiktreiber sind seit jeher fehleranfällig, und WebGL-Exploits sind ein bewährter Weg aus der Browser-Sandbox heraus.
Mediendekodierung. Video- und Audio-Codecs verarbeiten riesige Eingabemengen in C oder C++. Speicherkorruption in einem Codec führt oft direkt zur Code-Ausführung. Der bekannte BLASTPASS-Exploit von 2023 gegen iMessage nutzte einen Bildparser, dieselbe Art von Problemen gibt es auch im Browser.
WebAssembly und Web Workers. Parallel laufende Threads mit eigenem Speichermodell sind komfortabel, aber eine weitere Angriffsfläche, auf der sich Speicherfehler ausnutzen lassen.
Wie die Seite auf deinen Bildschirm kommt
Drive-by-Seiten tauchen nicht aus dem Nichts auf, sie werden ausgeliefert. Die drei wichtigsten Kanäle sind Malvertising, Watering-Hole-Angriffe und kompromittierte legitime Seiten.
Malvertising ist der günstigste Kanal. Die präparierte Seite sitzt im Iframe eines Werbebanners und erwischt jeden, der die Trägerseite lädt. Mehr dazu in Malvertising: When the Ad Is the Attack. Watering-Hole-Angriffe sind gezielter. Der Angreifer kompromittiert eine Seite, von der er weiss, dass seine Zielgruppe sie regelmässig besucht (eine Branchennews-Seite, eine Entwicklerdoku, ein Community-Forum), und platziert den Exploit dort.
Die dritte Variante sind direkt kompromittierte legitime Seiten. Ein gehacktes WordPress-Plugin, ein geklauter CDN-Account oder ein manipulierter Build-Hook reichen, um Skripte in eine vertrauenswürdige Seite einzuschleusen. Für Besucher ist der Unterschied nicht zu erkennen.
Das Zeitfenster zwischen Patch und Rollout
Chrome, Firefox und Safari patchen kritische Lücken innerhalb weniger Tage. Bei dir landen die Updates aber erst, wenn dein Browser sie holt und neu startet. Auf dem Desktop dauert das typischerweise 24 Stunden, auf Android manchmal Wochen, in verwalteten Enterprise-Umgebungen je nach Rollout-Fenster bis zu einem Monat.
Angreifer kennen dieses Zeitfenster genau. Sie warten auf den Disclosure-Tag, diffen den Patch, um die eigentliche Änderung zu finden, und bauen innerhalb weniger Stunden einen Exploit. Für einen kurzen, aber sehr lukrativen Zeitraum ist die Allgemeinheit wissentlich angreifbar. Auch in einer gut gewarteten Umgebung bist du in diesen Stunden exponiert.
Automatische Updates helfen, aber nicht ganz. Ein Browser, der seit fünf Tagen nicht neu gestartet wurde, läuft weiter auf dem alten Build, selbst wenn der Patch längst heruntergeladen ist.
Eindämmung, nicht Vermeidung
Drive-by-Downloads lassen sich nicht zuverlässig vermeiden, solange du das Web nutzt. Die Annahme, vertrauenswürdige Seiten seien sicher, hält der Realität nicht stand, weil Werbenetzwerke, Supply-Chain-Angriffe und Zero-Days auch die seriösesten Seiten erwischen. Der Fokus verschiebt sich von Vermeidung zu Eindämmung.
Eine isolierte Browser-Session nimmt den Exploit nach wie vor ernst, lässt ihn aber auf eine Umgebung treffen, die nicht dein Betriebssystem ist. Der Payload landet in einem Container, der nach deiner Session weggeworfen wird. Dein Laptop bleibt sauber. Zusammen mit einem schnellen Update-Zyklus für deinen Alltagsbrowser und der Erkenntnis, dass unbekannte Links nicht auf dem Produktivgerät landen müssen, schrumpft dein tatsächliches Risiko deutlich. Mehr zum Zero-Day-Zyklus findest du in Zero-Day Exploits.
Desktop-Power, auf jedem Gerät?
Probier Browser.lol kostenlos aus und sieh selbst, wie produktiv du mobil arbeiten kannst.
Desktop-Browser startenKein Download nötig • Läuft auf jedem Gerät
