Chrome 146 stärkt Schutz vor Cookie-Diebstahl mit gerätegebundenen Sitzungsanmeldeinformationen
**Google** hat in **Chrome** 146 für Windows Device Bound Session Credentials (DBSC) eingeführt, eine neue Abwehrmaßnahme gegen Infostealer-Malware. Diese Funktion bindet Benutzer-Sitzungen kryptografisch an spezifische Hardware, wodurch gestohlene Sitzungs-Cookies für Angreifer nutzlos werden.
## Chrome stärkt Sitzungssicherheit mit DBSC
**Google** verstärkt die Sicherheit von **Chrome** mit der Einführung von Device Bound Session Credentials (DBSC) in Version 146, zunächst für Windows-Benutzer. Diese Verbesserung zielt darauf ab, die Bedrohung durch Infostealer-Malware zu neutralisieren, indem die Ausnutzung gestohlener Sitzungs-Cookies verhindert wird. Die Unterstützung für macOS ist für eine zukünftige Version geplant.

Das DBSC-System etabliert eine kryptografische Verbindung zwischen der Sitzung eines Benutzers und der Hardware seines Geräts. Dabei wird das Trusted Platform Module (TPM) unter Windows und zukünftig die Secure Enclave unter macOS genutzt. Dies stellt sicher, dass die privaten Schlüssel, die zum Entschlüsseln sensibler Sitzungsdaten benötigt werden, sicher in der Hardware eingeschlossen bleiben.
Da die eindeutigen öffentlichen/privaten Schlüssel für die Verschlüsselung und Entschlüsselung sensibler Daten vom Sicherheitschip generiert werden, können sie nicht vom Rechner exportiert werden. Dies verhindert, dass ein Angreifer gestohlene Sitzungsdaten verwenden kann, da der eindeutige private Schlüssel, der sie schützt, nicht vom Rechner exportiert werden kann.
"Die Ausstellung neuer kurzlebiger Sitzungs-Cookies hängt davon ab, dass **Chrome** dem Server den Besitz des entsprechenden privaten Schlüssels nachweist", erklärte **Google** in seiner Ankündigung. Ohne diesen Schlüssel wird jedes exfiltrierte Sitzungs-Cookie sofort ungültig.
### So funktioniert DBSC
Ein Sitzungs-Cookie fungiert als langlebiger Authentifizierungstoken, der serverseitig basierend auf Benutzername und Passwort erstellt wird. Angreifer zielen oft mit spezialisierter Malware wie **LummaC2** auf diese Cookies ab, um herkömmliche Authentifizierungsmethoden zu umgehen.

*Browser-Server-Interaktion im Kontext des DBSC-Protokolls Quelle: Google*
"Entscheidend ist, dass hochentwickelte Malware, sobald sie Zugriff auf eine Maschine erlangt hat, die lokalen Dateien und den Speicher lesen kann, in denen Browser Authentifizierungs-Cookies speichern. Daher gibt es keine zuverlässige Möglichkeit, die Cookie-Exfiltration mit reiner Software auf jedem Betriebssystem zu verhindern", erklärte **Google**.
Das DBSC-Protokoll wurde mit Blick auf den Datenschutz entwickelt. Jede Sitzung wird durch einen eigenen Schlüssel gesichert, was verhindert, dass Websites Benutzeraktivitäten über Sitzungen oder Websites hinweg korrelieren können. Das Protokoll minimiert den Informationsaustausch und erfordert nur den öffentlichen Schlüssel pro Sitzung für den Besitznachweis, ohne die Weitergabe von Geräte-Identifikatoren zu ermöglichen.
### Branchenzusammenarbeit
Bei Tests mit Plattformen wie **Okta** verzeichnete **Google** eine signifikante Reduzierung von Sitzungsdiebstahlvorfällen. **Google** arbeitete mit **Microsoft** zusammen, um DBSC als offenen Webstandard zu entwickeln und dabei Feedback aus der Web-Sicherheits-Community einzubeziehen.
Websites können DBSC implementieren, indem sie dedizierte Registrierungs- und Aktualisierungsendpunkte zu ihren Backends hinzufügen, um die Kompatibilität mit bestehenden Frontends zu gewährleisten. Entwickler finden Implementierungsdetails in **Googles** Anleitung und Spezifikationen auf der Website des World Wide Web Consortium (W3C), mit einer Erläuterung auf GitHub.