Ursprungstest: Anmeldedaten für gerätegebundene Sitzungen in Chrome

José Luis Zapata

Device Bound Session Credentials (DBSC) ist eine neue Webfunktion, die Nutzersitzungen vor Cookie-Diebstahl und Session-Hijacking schützen soll. Diese Funktion kann jetzt als Ursprungstest in Chrome 135 getestet werden.

Hintergrund

Cookies spielen bei der modernen Webauthentifizierung eine wichtige Rolle, da sie es Nutzern ermöglichen, über mehrere Browsersitzungen hinweg angemeldet zu bleiben. Angreifer nutzen jedoch zunehmend gestohlene Authentifizierungs-Cookies, um Sitzungen zu hacken und die Multi-Faktor-Authentifizierung und andere Anmeldesicherheitsmechanismen zu umgehen.

Malware-Betreiber schleusen häufig Sitzungscookies von manipulierten Geräten ab, um unbefugten Zugriff auf Nutzerkonten zu ermöglichen. Da Cookies Inhabertokens sind, gewähren sie Zugriff, ohne dass ein Besitznachweis erforderlich ist. Das macht sie zu einem attraktiven Ziel für Angreifer.

Mit Device Bound Session Credentials (DBSC) soll der Cookie-Diebstahl verhindert werden, indem eine authentifizierte Sitzung erstellt wird, die an ein Gerät gebunden ist. Mit diesem Ansatz wird das Risiko verringert, dass gehackte Cookies von einem anderen Gerät aus auf Konten zugreifen können.

Funktionsweise

DBSC führt eine neue API ein, mit der Server eine authentifizierte Sitzung erstellen können, die an ein Gerät gebunden ist. Wenn eine Sitzung gestartet wird, generiert der Browser ein öffentliches/privates Schlüsselpaar und speichert den privaten Schlüssel sicher mit einem hardwaregestützten Speicher, z. B. einem Trusted Platform Module (TPM), sofern verfügbar.

Der Browser gibt dann ein reguläres Sitzungscookie aus. Während der Sitzungsdauer bestätigt der Browser regelmäßig, dass er den privaten Schlüssel hat, und aktualisiert das Sitzungscookie. Die Lebensdauer des Cookies kann so kurz eingestellt werden, dass ein Diebstahl des Cookies für Angreifer keinen Vorteil bietet.

Schlüsselkomponenten

  • Sitzungsregistrierung:

    • Wenn sich ein Nutzer anmeldet, fordert der Server über den HTTP-Header Sec-Session-Registration eine gerätegebundene Sitzung an.
    • Der Browser generiert ein neues Schlüsselpaar und speichert den privaten Schlüssel sicher.
    • Außerdem wird ein kurzlebiges Authentifizierungs-Cookie erstellt und an dieses Schlüsselpaar gebunden.
    • Der Server verknüpft die Sitzung mit dem entsprechenden öffentlichen Schlüssel, damit sie nur auf dem ursprünglichen Gerät verwendet werden kann.

  • Sitzungsaktualisierung und Besitznachweis:

    • Wenn das kurzlebige Cookie abläuft, löst Chrome eine Sitzungsaktualisierung aus.
    • Der Browser sendet eine Anfrage an einen serverdefinierten Aktualisierungsendpunkt (der während der Sitzungsregistrierung angegeben wurde) und, falls der Server eine solche bereitstellt, eine signierte Herausforderung mit dem Sec-Session-Challenge-Header.
    • Der Server prüft den Besitznachweis, indem er die Antwort validiert, die mit dem privaten Schlüssel der Sitzung signiert wurde.
    • Ist das der Fall, stellt der Server ein neues kurzlebiges Cookie aus, damit die Sitzung fortgesetzt werden kann.

Ein Vorteil dieses Ansatzes ist, dass Chrome Anfragen verschiebt, bei denen das aktualisierte kurzlebige Cookie andernfalls fehlt. Dadurch bleiben sitzungsgebundene Cookies während der gesamten Sitzung verfügbar und Entwickler können sich auf sie sicherer verlassen als bei Ansätzen, bei denen Cookies ohne automatische Verlängerung ablaufen oder verschwinden.

Beispielimplementierung

Ein Server kann eine gerätegebundene Sitzung so anfordern:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256);path="/refresh";challenge="12345"

Wenn die Sitzung aktiv ist, kann der Server sie mit einem Abfrage-Antwort-Austausch bestätigen:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "verify-session"

Der Browser antwortet mit:

POST /refresh
Sec-Session-Response: "signed-proof"

Vorteile

  • Reduziert den Cookie-Diebstahl: Auch wenn Sitzungscookies gestohlen werden, können sie nicht auf einem anderen Gerät verwendet werden.
  • Verbessert die Sicherheit ohne größere Änderungen an der UX: Funktioniert transparent im Hintergrund, ohne dass zusätzliche Nutzerinteraktionen erforderlich sind.
  • Reduziert die Abhängigkeit von langlebigen Sitzungscookies: Kurzlebige Cookies werden automatisch aktualisiert, solange die Sitzung auf dem ursprünglichen Gerät gültig bleibt.
  • Unterstützt standardmäßige kryptografische Mechanismen: Nutzt bei Verfügbarkeit TPM-gestützten sicheren Speicher, um einen starken Schutz vor Datenexfiltration zu bieten.

Datenschutz- und Sicherheitsaspekte

DBSC soll die Sicherheit verbessern und gleichzeitig die Privatsphäre der Nutzer schützen:

  • Keine zusätzlichen Tracking-Vektoren: Jede Sitzung ist einem eindeutigen Schlüsselpaar zugeordnet, wodurch ein sitzungsübergreifendes Tracking verhindert wird.
  • Kein langfristiger Geräte-Fingerprinting: Server können unterschiedliche Sitzungen auf demselben Gerät nicht miteinander in Beziehung setzen, es sei denn, dies wird vom Nutzer ausdrücklich erlaubt.
  • Von Nutzern löschbar: Sitzungen und Schlüssel werden gelöscht, wenn der Nutzer Websitedaten löscht.
  • Entspricht den Cookie-Richtlinien: Für DBSC gilt dieselbe websitebasierte Einschränkung wie für Cookies, sodass keine websiteübergreifenden Datenlecks auftreten.

Jetzt ausprobieren

Der Ursprungstest für Anmeldedaten für gerätegebundene Sitzungen ist ab Chrome 135 verfügbar.

Für lokale Tests

So testen Sie DBSC lokal:

  • Gehen Sie zu chrome://flags#device-bound-session-credentials und aktivieren Sie die Funktion.

Für öffentliche Tests

So testen Sie DBSC mit dem Ursprungstest in einer öffentlichen Umgebung:

  1. Rufen Sie die Seite mit Chrome Origin Trials auf und registrieren Sie sich.

  2. Fügen Sie das bereitgestellte Token den HTTP-Headern Ihrer Website hinzu:

    Origin-Trial: <your-trial-token>

Ressourcen

Mitmachen und die Zukunft der Websicherheit mitgestalten

Helfen Sie uns, die Webauthentifizierung sicherer zu machen. Wir empfehlen Webentwicklern, DBSC zu testen, in ihre Anwendungen einzubinden und Feedback zu geben. Sie können sich mit uns auf GitHub austauschen oder an den Diskussionen der Arbeitsgruppe für Webanwendungssicherheit teilnehmen.

Durch die Implementierung von DBSC können wir gemeinsam die Risiken von Session-Hijacking reduzieren und die Authentifizierungssicherheit für Nutzer verbessern. Starten Sie noch heute und helfen Sie mit, die Zukunft der Websicherheit zu gestalten.