Headless-Browser

Ein Headless-Browser nutzt dieselbe Rendering-Engine wie ein normaler Browser, etwa Chromium oder WebKit, lässt jedoch das Bildschirmfenster weg. Ein Skript steuert ihn programmgesteuert, um Seiten zu laden, JavaScript auszuführen, Elemente anzuklicken und das resultierende DOM auszulesen. Da er die vollständige Engine ausführt, kann er Single-Page-Anwendungen und dynamische Inhalte verarbeiten, die ein einfacher HTTP-Client nicht bewältigt.

Genau diese Leistungsfähigkeit macht Headless-Browser für Angreifer attraktiv. Sie können das JavaScript ausführen, auf das sich Fingerprinting- und Challenge-Skripte stützen, und besiegen so Abwehrmechanismen, die davon ausgehen, dass ein skriptgesteuerter Client keinen Code auf der Seite ausführen kann. In großem Maßstab kann eine einzige Maschine viele Headless-Instanzen parallel steuern, von denen jede vorgibt, ein unabhängiger Besucher zu sein.

Headless-Umgebungen hinterlassen jedoch erkennbare Spuren. Historisch legten sie offensichtliche Marker offen, etwa ein HeadlessChrome-Token im User Agent oder ein navigator.webdriver-Flag. Selbst wenn diese behoben sind, bleiben subtilere Inkonsistenzen: fehlende oder nachgeahmte Browser-APIs, fehlende Plugins, ungewöhnliches Rendering von Grafiken und Schriftarten, fehlende Hardware-Sensoren und ein Timing-Verhalten, das sich von einer interaktiven Sitzung unterscheidet.

Betreiber von bösartigem Headless-Datenverkehr versuchen, diese Spuren zu tilgen, indem sie Eigenschaften patchen, Werte fälschen und gefälschte menschliche Eingaben hinzufügen. Die Erkennung konzentriert sich daher auf die interne Konsistenz und prüft, ob die vielen unabhängigen Signale, die ein Browser offenlegt, tatsächlich übereinstimmen, da eine vollständig in sich konsistente Fälschung über jede Oberfläche hinweg schwer aufrechtzuerhalten ist.