UserAgent-Konsistenz prüfen: Die vier Schwachstellen einer UA-Nichtübereinstimmung

Auf Prüfseiten zeigt das UA-Feld einen normalen Wert an, doch wenige Tage nach der Kontoanmeldung erscheint trotzdem eine Verifizierungsabfrage. Manche wechseln daraufhin sofort den UA oder installieren ein weiteres UA-Plugin. Die Folge: Auffälligkeiten treten noch häufiger auf.

In den meisten Fällen steckt das Problem in der Konsistenz. Der UA ist ein einzelnes Feld, aber die Plattform liest es an mehr als einer Stelle. Ändert man nur eine davon, behalten die übrigen ihren alten Wert, und beim gegenseitigen Abgleich entsteht ein Widerspruch.

Der erste Schritt jeder UA-Prüfung ist die Frage, ob dieses Feld auf allen Offenlegungsflächen dieselbe Geschichte erzählt; erst danach folgt der Abgleich mit Gerät, Region und weiteren Parametern. In diesem Artikel zerlegen wir zuerst die drei Kanäle, über die Plattformen den UA lesen, und listen dann vier Signalkategorien auf, durch die sich eine Abweichung verrät. Am Ende steht eine Checkliste mit fünf Vergleichspunkten bis hin zur Konfiguration im Antidetect-Browser.

Die drei Kanäle, über die Plattformen den UA lesen

Denselben UA-Wert liest die Plattform tatsächlich an drei Stellen: HTTP-Request-Header, Client-Hints-Header und Seitenskript. Die drei Kanäle sind voneinander unabhängig und lassen sich einzeln gegenprüfen.

Beim Absenden einer Anfrage ist der UA-String im Header der früheste Kanal; die Website liest ihn, bevor sie die Seite überhaupt ausliefert. Seit Chrome 89 meldet der Browser Geräteinformationen separat über die Sec-CH-UA-Headerreihe; Browsermarke, Plattform und Plattformversion belegen jeweils einen eigenen Header, den die Website bei Bedarf abfragt. Die Client-Hints-Dokumentation auf MDN beschreibt den Aufbau dieser Header sehr anschaulich.

Der dritte Kanal liegt im Seitenskript. navigator.userAgent und navigator.userAgentData melden die Browser- und Plattforminformationen ein weiteres Mal von innerhalb der Seite. Theoretisch stimmen alle drei Messwerte wortwörtlich überein. Wird eine Stelle einzeln verändert, ziehen die anderen beiden nicht nach.

Genau hier haken UA-Plugins. Die meisten ersetzen nur den UA-String im Request-Header, während das Seitenskript weiterhin den Originalwert liest; die beiden Kanäle widersprechen sich auf der Stelle. Solche Widersprüche aufzudecken erfordert keine hohe Technik: Ein Risikokontrollskript braucht nur beide Messwerte zu vergleichen.

Ein Hintergrund ist noch zu erwähnen: Chrome friert die Informationen im klassischen UA-String schrittweise ein, der hintere Teil der Versionsnummer ist bereits fixiert, und weitere Details wandern in die Client Hints. Der Spielraum, allein am UA-String zu drehen, schrumpft. Umso entscheidender ist, ob die Kanäle untereinander aufgehen.

Was eine UA-Abweichung verrät: vier Signalkategorien

Für sich allein ist ein UA weder echt noch gefälscht; erst im Verbund der Signale zeigt sich die Schwachstelle. Die meisten Abweichungen bei Problemen mit der Umgebung fallen in eine der folgenden vier Kategorien.

Erste Kategorie: Die Kanäle widersprechen sich. Im Request-Header meldet sich Chrome 126, das Seitenskript liest noch Chrome 118; oder die im Sec-CH-UA deklarierte Marke stimmt nicht mit dem überein, was navigator.userAgentData zurückgibt. Für solche Messwerte gibt es praktisch nur eine Erklärung: Der UA wurde einzeln verändert, und die Änderung hat nicht alle Kanäle abgedeckt.

Zweite Kategorie: Die Deklaration widerspricht den Hardwareparametern. Im UA steht iPhone, doch der Bildschirm zeigt eine Desktop-Auflösung von 1920×1080 bei null Touchpunkten; der UA behauptet Windows, doch der GPU-Renderer meldet einen Apple-Chip. Hardwareparameter sind Messwerte aus der realen Umgebung, der UA dagegen eine frei wählbare Angabe. Stellt man beide gegeneinander, tritt die Schwachstelle viel deutlicher zutage als der UA selbst. Warum Fingerprint-Randomisierung unsicher ist zerlegt die Ursachen solcher Widersprüche Parameter für Parameter.

Dritte Kategorie: Widerspruch zur Umgebungskombination. Die Ausgangs-IP sitzt in den USA, der UA verrät jedoch einen chinesischsprachigen Browser, und Sprachliste sowie Zeitzone weisen in eine andere Region. UA, System, Sprache, Zeitzone und IP sollten eigentlich gemeinsam dasselbe Regionsprofil ergeben; weicht einer dieser Punkte ab, wirkt das gesamte Profil verdächtig. Solche Widersprüche lassen sich nicht per UA-Wechsel beheben; anzupassen ist die Umgebungskonfiguration.

Vierte Kategorie: Diskrepanz zu Merkmalen der Transportschicht. Die Merkmale aus dem TLS-Handshake wirken wie ein Skriptwerkzeug oder wie eine sehr alte Browserversion, während der Request-Header ein aktuelles Chrome meldet. Merkmale der Transportschicht sind schwerer zu verändern als der UA, und der Abgleich beider Seiten kostet die Plattform kaum Aufwand.

Von den vier Signalkategorien lassen sich die ersten drei bereits in der Phase der Umgebungskonfiguration vermeiden; die vierte hängt von der Art des Verbindungsaufbaus ab. Achte im Alltag auf die ersten drei; sobald Messwerte widersprechen, steht die Konfiguration erneut auf dem Prüfstand.

So läuft die Konsistenzprüfung: fünf Vergleichspunkte

Geprüft wird an fünf Vergleichspunkten, nicht auf einer einzelnen Seite.

1. Kanalabgleich: Öffne eine Prüfseite aus der Umgebung, sieh dir im Network-Panel der Entwicklertools den UA und Sec-CH-UA in den Request-Headern an und gleiche beides mit dem Messwert von navigator.userAgent in der Konsole ab; alle drei Stellen müssen übereinstimmen.

2. Hardwareabgleich: Gleiche den im UA deklarierten Gerätetyp einzeln mit Bildschirmauflösung, Touch-Fähigkeit, GPU-Renderer, Kernanzahl und Arbeitsspeicher ab; welche Geräteart die Deklaration auch nennt, die Messwerte müssen zu ihr passen.

3. Regionsabgleich: Prüfe, ob UA-Sprache, Browser-Sprachliste, Zeitzone und Ausgangs-IP ins selbe Regionsprofil gehören; bei einer mobilen Deklaration müssen auch die Merkmale des Mobilfunknetzes dazu passen.

4. Versionsabgleich: Die Browserversion im UA sollte im verbreiteten Bereich des Zielmarkts liegen; eine zu neue Version oder ein vor Jahren stehengebliebener Altstand ist ebenso ein Auffälligkeitssignal wie eine Version, die nicht zum Verhalten der Engine passt.

5. Nachkontrolle mit Protokoll: Nach jeder Konfigurationsänderung die Prüfseite erneut durchlaufen und die Messwerte dokumentieren; wenn die Umgebung später auffällig wird, sind diese Aufzeichnungen der Ausgangspunkt der Fehlersuche.

Bei den Werkzeugen sammelt CreepJS gezielt Widersprüche zwischen den Messwerten des Seitenskripts und den Angaben des Browsers; testet man damit eine Umgebung mit verändertem UA, werden kollidierende Kanäle direkt markiert. Umfassende Prüfseiten wie Browserscan eignen sich für die Gesamtablesung der fünf Parametergruppen; setze beide Werkzeuge kombiniert ein. Der UA ist nur eines der Signale in der Umgebungskonsistenz; für die Prüf-Reihenfolge der gesamten Umgebung enthält der Artikel zur Konsistenzprüfung gegen Kontoverknüpfung eine Sechs-Punkte-Checkliste, die sich gut mit den fünf Vergleichspunkten hier zusammen verwenden lässt.

Den UA im Antidetect-Browser passend konfigurieren

Beim Abarbeiten der fünf Vergleichspunkte ist der effizienteste Weg, UA und zugehörige Parameter gemeinsam generieren zu lassen, statt alles von Hand einzutragen. MostMate ist ein einsteigerfreundlicher AI-Antidetect-Browser, der für jedes Konto eine eigene Browserumgebung bereithält; die UA-Konsistenz ist genau Teil seines Umgebungskonfigurationsablaufs. Bevor du loslegst, kannst du auf der Produktseite von MostMate den gesamten Erstellungsprozess durchgehen.

Beim Anlegen einer Umgebung wählst du zuerst Betriebssystem und Browserversion, der User-Agent wird daraufhin generiert und lässt sich bei Bedarf bearbeiten. Sprach-, Zeitzonen- und Standorteinstellung stehen standardmäßig auf „Basierend auf IP konfigurieren“. Sobald der Exit-Proxy gewählt ist, passt die Regionskombination dieser Punkte mit dem UA automatisch zusammen. Das Fingerprint-Vorschaupanel listet in Echtzeit die aktuellen Werte von User-Agent und allen übrigen Parametern. Schon beim Anlegen der Umgebung siehst du, ob die Konfiguration in sich stimmig ist, statt nach dem Start nachbessern zu müssen.

Wie fein du konfigurierst, bleibt dir überlassen. In den manuellen Fingerprint-Einstellungen wählst du elf Punkte wie UA, Bildschirm, Zeitzone und Sprache einzeln aus; die empfohlene Konfiguration auf der Startseite erzeugt dagegen nach Gerätelogik direkt eine konsistente Umgebung. Beide Wege haben ihre eigenen Einsatzbereiche.

Wichtig ist auch die Grenze dieser Betrachtung: Die Konsistenz von UA und Umgebungskonfiguration reduziert eine Kategorie von Offenlegungssignalen. Ob ein Konto von der Plattform verknüpft wird, hängt darüber hinaus von den Plattformregeln, den Beziehungen zwischen Konten und dem Nutzungsverhalten ab; die Umgebungskonfiguration adressiert davon allein die Umgebungsebene.

Häufige Fragen

Warum fällt man mit einem UA-Plugin eher auf?

Plugins ändern meist nur den Kanal des Request-Headers, während Seitenskript und Client Hints weiterhin den Originalwert lesen. Sobald die Kanäle widersprechen, steht der geänderte UA gewissermaßen in den Messwerten. Der Widerspruch selbst ist das Auffälligkeitssignal und fällt mehr auf als gar keine Änderung.

Ist bei der UA-Versionsnummer neu immer besser?

Entscheidend ist, im verbreiteten Versionsbereich des Zielmarkts zu liegen. Eine Version, die neuer als die neueste ist oder auf einem Stand von vor Jahren stehen geblieben ist, gilt ebenfalls als Auffälligkeitssignal. Die Version muss zudem zum Verhalten der Engine passen; das bloße Jagen nach der neuesten Nummer bringt nichts.

Kann man in einer Desktop-Umgebung einen mobilen UA verwenden?

Ja, aber Parameter wie Bildschirmauflösung, Touch-Fähigkeit und Gerätespeicher müssen dann gemeinsam auf ein mobiles Gerät eingestellt werden. Wie diese Parameter zusammenwirken, zeigt der Artikel Bildschirmauflösung und Fenstergröße als Fingerprint im Detail.

Wenn die Prüfseite den UA als konsistent anzeigt, gibt es dann keine Probleme mehr?

Die Messwerte einer Prüfseite decken vor allem Parameter ab, die das Seitenskript lesen kann; Merkmale der Transportschicht und manche Client-Hints-Details stecken nicht unbedingt darin. Sicherer ist es, erst nach dem Durchlaufen aller fünf Vergleichspunkte ein Fazit zu ziehen.

Fazit

Das Ziel der UA-Prüfung ist, dass die drei Kanäle und die gesamte Umgebung eine stimmige Geschichte ergeben: Die Kanäle widersprechen sich nicht, Deklaration und Hardwaremesswerte passen zusammen, die Regionskombination ist plausibel, der Versionsbereich liegt im Üblichen. Wer die fünf Vergleichspunkte einmal der Reihe nach durchgeht, beseitigt die meisten Schwachstellen auf UA-Ebene, bevor die Umgebung live geht. Die Prüfung vor dem Livegang kostet am wenigsten.

Bei einer neuen Umgebung erst diese Prüfung durchzugehen, bevor das Konto startet, ist weit weniger mühsam, als nach einer Verifizierungsabfrage zurückzukommen und den UA zu wechseln. Wenn du Umgebungen nach diesem Ablauf verwalten möchtest, kannst du MostMate herunterladen und UA samt gesamter Umgebung in einem Rutsch einrichten: vom Wählen des Systems über das Konfigurieren des Proxys bis zum Abgleich der Fingerprint-Vorschau.