Google rollt die Technologie Device Bound Session Credentials (DBSC) nun breit für Nutzerinnen und Nutzer von Chrome 146 unter Windows aus. Ziel ist es, eine der effektivsten Angriffstechniken im Web – den Diebstahl von Session-Cookies – deutlich zu erschweren und so Kontoübernahmen und Datendiebstahl zu reduzieren.
Session-Hijacking: Warum gestohlene Cookies so gefährlich sind
Beim Session-Hijacking entwenden Angreifer Sitzungs-Cookies aus dem Browser und nutzen sie, um sich ohne Passwort und ohne Zwei-Faktor-Authentifizierung Zugriff auf Konten zu verschaffen. Laut Branchenanalysen, etwa dem Verizon Data Breach Investigations Report, zählen kompromittierte Zugangsdaten seit Jahren zu den häufigsten Ursachen erfolgreicher Sicherheitsvorfälle.
In der Praxis kommen dafür vor allem Info-Stealer-Trojaner zum Einsatz, die sich häufig über gecrackte Software, vermeintliche Tools oder E-Mail-Anhänge verbreiten. Bekannte Malware-Familien wie Atomic Stealer, Lumma oder Vidar Stealer sind darauf spezialisiert, Cookies, Session-Tokens, gespeicherte Passwörter, Autofill-Daten und Kryptowallets automatisiert abzugreifen und an die Angreifer zu übermitteln.
Problematisch ist insbesondere, dass viele dieser Session-Tokens lange gültig bleiben. Für Cyberkriminelle bedeutet das wochen- oder monatelangen Zugang zu E-Mail-Konten, Cloud-Speichern, Banking- oder Unternehmenssystemen – oft vollständig an Sicherheitskontrollen vorbei. Auf Untergrundmarktplätzen werden solche Datensätze systematisch gehandelt und in Folgeangriffen wiederverwendet.
Wie Device Bound Session Credentials in Chrome 146 funktionieren
Mit DBSC verfolgt Google das Ziel, gestohlene Cookies kryptografisch zu entwerten, sobald sie das Ursprungsgerät verlassen. Kernidee ist, jede Web-Sitzung an ein bestimmtes Endgerät zu binden, statt ausschließlich auf serverseitige Cookies zu vertrauen.
Kryptografische Bindung an das Endgerät: TPM und Secure Enclave
DBSC nutzt hardwaregestützte Sicherheitsmodule, etwa das Trusted Platform Module (TPM) unter Windows oder die Secure Enclave auf Apple-Systemen. Darin generiert der Browser ein Schlüsselpaar aus öffentlichem und privatem Schlüssel. Der private Schlüssel verbleibt unveränderlich auf dem Gerät und kann weder ausgelesen noch exportiert werden.
Authentifiziert sich ein Nutzer bei einem Dienst, fordert Chrome nicht nur einen herkömmlichen Cookie an, sondern einen Sitzungstoken, das an dieses Schlüsselpaar gebunden ist. Der öffentliche Schlüssel fungiert gegenüber dem Server als Marker, dass der Browser über den zugehörigen privaten Schlüssel verfügt und somit tatsächlich das autorisierte Gerät repräsentiert.
Kurzlebige Cookies und kontinuierlicher Besitznachweis
DBSC verändert zudem das Lebenszyklusmodell der Cookies. Neue, kurzlebige Session-Cookies werden nur dann ausgestellt, wenn Chrome dem Server den Besitz des privaten Schlüssels nachweist. Dies geschieht über etablierte kryptografische Verfahren, etwa durch Signatur einer serverseitigen Herausforderung.
Für Angreifer bedeutet das: Selbst wenn ein Info-Stealer die Cookies aus dem Browser stiehlt, laufen diese sehr schnell ab und können ohne den privaten Geräteschlüssel nicht verlängert werden. Die auf Untergrundforen gehandelten Cookies verlieren damit einen Großteil ihres Wertes. Systeme ohne sichere Schlüsselspeicher unterstützen ein Fallback-Verhalten, sodass die Anmeldung zwar weiterhin funktioniert, jedoch ohne die zusätzlichen Schutzmechanismen von DBSC.
Einführung, Standardisierung und Bedeutung für Unternehmen
Aktuell ist DBSC standardmäßig für Chrome 146 unter Windows aktiviert. Unterstützung für macOS soll in kommenden Versionen folgen. Nach Angaben von Google zeigen bereits erste Auswertungen aus Beta-Phasen eine messbar geringere Erfolgsquote bei Session-Diebstahl, was den praktischen Nutzen des Ansatzes unterstreicht.
DBSC erfordert neben dem Browser auch Anpassungen auf Serverseite, damit Webanwendungen mit den neuen, gerätegebundenen Session-Credentials umgehen können. Gemeinsam mit Microsoft arbeitet Google daran, DBSC als offenen Web-Standard zu etablieren, um eine spätere Unterstützung in weiteren Browsern und Enterprise-Produkten zu ermöglichen.
Privatsphäre, Tracking-Schutz und regulatorische Anforderungen
Ein zentraler Designgrundsatz von DBSC ist die Wahrung der Privatsphäre. Die Architektur ist so ausgelegt, dass Websites gerätegebundene Credentials nicht für Cross-Site-Tracking missbrauchen können. Server erhalten im Wesentlichen nur den öffentlichen Schlüssel als Nachweis des Besitzes – ohne dauerhafte Gerätekennungen oder Attestierungsdaten, die ein Fingerprinting erleichtern würden.
Für Unternehmen entsteht damit eine seltene Kombination aus stärkerem Schutz vor Account-Übernahmen und konformer Datenminimierung. Vor dem Hintergrund strenger Datenschutzvorgaben in der EU und weltweit kann DBSC helfen, Sicherheitsziele zu erreichen, ohne zusätzliche personenbezogene Identifikatoren einzuführen.
Organisationen sollten frühzeitig prüfen, inwieweit ihre Webanwendungen DBSC unterstützen können, Richtlinien für den Einsatz moderner Browser-Sicherheitsfunktionen definieren und den Schutz vor Info-Stealer-Malware auf Endgeräten stärken. Wer Browser aktuell hält, Endpoint-Schutz ernst nimmt und gerätegebundene Sitzungs-Credentials einführt, senkt das Risiko von Session-Hijacking spürbar und erschwert Angreifern das Geschäftsmodell mit gestohlenen Cookies.
