demo · v135

Cookie replay attack lab

DBSC's headline use case from the Chrome blog post: session cookie theft no longer hands the attacker the session. This lab registers a real backend session, then sends refresh proofs signed by either Alice's registered key or an attacker key that only copied the cookie value.

Backend-backed The server stores Alice's public key from a real dbsc+jwt registration proof. Replay attempts call the same /refresh endpoint and are accepted or rejected by backend signature verification.
WebCrypto: ?

device #1

Alice (real user)
private key: not yet generated

server

app.example.com
session cookie issued: —
bound public key: —

device #2

Mallory (exfiltrated cookie)
stolen cookie: —
private key: attacker's own (mismatched)

the protocol

// Real flow happens in HTTP headers.
Secure-Session-Registration: (ES256);path="...";challenge="..."
Secure-Session-Response: <ES256 dbsc+jwt with public JWK>

// On every refresh, server issues a fresh challenge.
Secure-Session-Challenge: "nonce";id="session"
Secure-Session-Response: <ES256 dbsc+jwt signed by bound key>

// Server verifies sig with the bound public key.
// Stolen cookie + attacker's key → signature fails → 401.

see also