Session Token Replay

Description

Bearer‑only tokens stolen from a device (via phishing, malware, backups, or MITM) can be reused from another host to access APIs. Without device binding or proof‑of‑possession, backend services cannot distinguish legitimate device traffic from replayed tokens.

Examples

Extract Token from App Storage (Android)

If the app is debuggable or run-as is permitted:

adb shell run-as com.example.app cat /data/data/com.example.app/shared_prefs/auth.xml | rg -i access_token

Intercept and Replay via Proxy

Capture an Authorization header, then replay from a different client:

mitmproxy  # intercept a request and copy the Bearer token
curl -H "Authorization: Bearer <TOKEN>" https://api.example.com/v1/me

If the API accepts the request from a new IP/device, the token is replayable.

Remediation

1. Bind tokens to device keys
   • Use DPoP, mTLS, or token binding; require proof keys derived from hardware‑backed keystores.
2. Store tokens securely
   • Use Android Keystore/iOS Keychain; encrypt at rest; avoid plaintext shared prefs.
3. Limit replay window
   • Short token lifetimes, rotate refresh tokens, revoke on anomaly (new IP/UA/geo/device fingerprint).
4. Detect and challenge
   • Detect same token from multiple devices and trigger step‑up authentication.