Worker Rule Injection Demo

S5 — Session cookie vault

Origin issues weak PHPSESSID / AUTHTOKEN. This host vaults them and gives the browser only opaque __rs_sid (Secure; HttpOnly; SameSite=Strict).

Key questions

Question

Does S5 use one Durable Object for every customer session?

No. Each high-entropy tokenId selects its own SessionVault object. One hot session still converges on one single-threaded object; different sessions are sharded.

Success criteria / proof

  1. Client receives only the vault token.Issue persists origin session cookies before setting the hardened __rs_sid cookie.
  2. Authenticated requests restore origin state.Whoami reaches the origin with vaulted session cookies while the client’s raw session names are stripped.
  3. Sessions are isolated by token.Each high-entropy token ID selects its own SessionVault Durable Object; no customer-wide object or KV map is used.
  4. Rotation preserves the client token.Origin cookie rotation updates the same token’s durable record.
  5. Logout and invalid state fail closed.Revoke, expiry, tampering, missing records, and Durable Object errors prevent authenticated access.
Direct Origins5-origin.thecompany-lab.com
Capability Workers5.thecompany-lab.com

1. Browser verification

Session controls
Direct comparison
Origin /issueOrigin /whoami

Validation result

Issue a session to begin the validation.

The result shows pass/fail checks without printing session values. Use DevTools → Application → Cookies to confirm the browser has __rs_sid, not the origin session names.

3. Command-line verification (copy and run)

Step 1 — Observe the before cookie boundary

The direct origin sends its weak session cookies directly to the client.

rm -f /tmp/s5-origin.txt
curl -sS -c /tmp/s5-origin.txt -D -   https://s5-origin.thecompany-lab.com/issue -o /dev/null
cat /tmp/s5-origin.txt

Step 2 — Issue the after session

The capability should issue only the opaque client token and must not expose origin session cookies.

rm -f /tmp/s5-cap.txt
curl -sS -c /tmp/s5-cap.txt -b /tmp/s5-cap.txt -D -   https://s5.thecompany-lab.com/issue -o /tmp/s5-issue.json
cat /tmp/s5-cap.txt
# Inspect headers: expect __rs_sid; no PHPSESSID/AUTHTOKEN

Step 3 — Verify the vaulted request

The origin should receive the vaulted session values while the client supplies no raw origin cookies.

curl -sS -c /tmp/s5-cap.txt -b /tmp/s5-cap.txt   https://s5.thecompany-lab.com/whoami | jq '{source, rawClientSession, received: (.received | keys)}'

Step 4 — Verify rotation keeps the client token

Origin rotation should update the vault mapping behind the same __rs_sid.

curl -sS -c /tmp/s5-cap.txt -b /tmp/s5-cap.txt   https://s5.thecompany-lab.com/rotate | jq .
curl -sS -b /tmp/s5-cap.txt   https://s5.thecompany-lab.com/whoami | jq '{source, rawClientSession}'

Step 5 — Verify revoke

After logout, the next authenticated request should fail closed.

curl -sS -c /tmp/s5-cap.txt -b /tmp/s5-cap.txt -D -   https://s5.thecompany-lab.com/logout -o /dev/null
curl -sS -b /tmp/s5-cap.txt -o /dev/null -w '%{http_code}\n'   https://s5.thecompany-lab.com/whoami   # expect 401 or redirect