Haxoris Wiki

Session Token Replay

How Session Token Replay works

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.

Session Token Replay in practice

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.

How to fix and prevent Session Token Replay

  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.

Last updated

References