Worker Rule Injection Demo

S6 — Leaked-password forced change

Key questions

Question

What happens when HIBP, email, or native bot controls are unavailable?

HIBP sends only a five-character SHA-1 prefix, uses a 60-second prefix-only cache, and bounds misses at two seconds. Initial login fails open on HIBP error; new-password confirmation fails closed. Cloudflare Email Service is the approved provider.

Success criteria / proof

  1. Only breached valid logins enter remediation.The edge requires both the breach result and authoritative origin credential validation before creating pending state.
  2. No session is issued on remediation.Browser responses redirect to the remediation page; API responses return the password-change-required response without an app session.
  3. Clean logins remain normal.A clean, valid login passes through the normal origin authentication path without pending remediation.
  4. OTP mutation order is enforced.Both mutation routes require CSRF, then Turnstile, before OTP state changes, email, validation, or reset.
  5. Secrets stay out of edge storage.The edge stores only pending metadata and OTP hashes; login and new-password material is not persisted or logged.
  6. Provider and native controls remain separate.Cloudflare Email Service handles delivery, while native Bot Management does not replace Worker-level CSRF and Turnstile checks.
Direct Origins6-origin.thecompany-lab.com
Capability Workers6.thecompany-lab.com

1. Seeded demo credentials

These are intentionally public, synthetic PoC accounts seeded by the S6 origin. They are not real credentials. Use them to reproduce the before/after behavior:

FixtureEmailPasswordExpected on capability
Operator-approved breached + valid credential alice@thecompany-lab.com password Remediation, no session
Operator-approved clean + valid credential bob@thecompany-lab.com Str0ng-Unique-Passphrase!2026 Normal login success

The breached fixture is intentionally known to HIBP. The origin persists password resets, so use an isolated deployment for the full remediation flow.

Authentication flow
Capability loginOrigin loginRemediation page

2. Browser verification

Run a read-only validation. Each row names the action, expected result, observed result, and status; no account or origin state is changed.

Not run yet.

3. Command-line verification (copy and run)

Run these steps in one terminal. Set the fixture variables in your shell using the seeded values above; do not put credential values directly into the commands.

Step 1 — Observe the before login

The direct origin handles the login normally and may issue an application session.

: "${S6_EMAIL:?Set S6_EMAIL in your shell}"
: "${S6_PASSWORD:?Set S6_PASSWORD in your shell}"
: "${S6_CLEAN_EMAIL:?Set S6_CLEAN_EMAIL in your shell}"
: "${S6_CLEAN_PASSWORD:?Set S6_CLEAN_PASSWORD in your shell}"
curl -sS -D - -X POST https://s6-origin.thecompany-lab.com/login   -H 'Content-Type: application/json' -H 'Accept: application/json'   -d "{"email":"${S6_EMAIL}","password":"${S6_PASSWORD}"}"

Step 2 — Verify the intercepted API response

The same breached-valid fixture through the capability should return the password-change-required response without an app session.

curl -sS -D - -X POST https://s6.thecompany-lab.com/login   -H 'Content-Type: application/json' -H 'Accept: application/json'   -d "{"email":"${S6_EMAIL}","password":"${S6_PASSWORD}"}"

Step 3 — Start the browser remediation handoff

Use form encoding to observe the redirect and capture the scoped CSRF cookie.

rm -f /tmp/s6.txt
curl -sS -D /tmp/s6-login.headers -o /dev/null -c /tmp/s6.txt   -X POST https://s6.thecompany-lab.com/login   -H 'Content-Type: application/x-www-form-urlencoded'   --data-urlencode "email=${S6_EMAIL}" --data-urlencode "password=${S6_PASSWORD}"
cat /tmp/s6-login.headers
cat /tmp/s6.txt

Step 4 — Inspect the remediation form

The page should expose the CSRF-bound OTP flow only after the intercepted login handoff.

curl -sS -b /tmp/s6.txt   https://s6.thecompany-lab.com/__rs/pwned   | grep -E 'csrf|turnstile|otp' | head

Step 5 — Verify the clean-login path

Use the approved clean fixture to confirm normal login remains separate from remediation.

curl -sS -D - -X POST https://s6.thecompany-lab.com/login   -H 'Content-Type: application/json' -H 'Accept: application/json'   -d "{"email":"${S6_CLEAN_EMAIL}","password":"${S6_CLEAN_PASSWORD}"}"