Cookie-Conditional Sink Discovery

A "sink" (eval, deserialize, exec, template render) may behave differently — or not fire at all — depending on which session cookies are present. Recon MUST enumerate every cookie the app sets and re-test each candidate sink with and without each cookie before declaring the sink unreachable. Skipping this step is the most common cause of exploit handing back a false "blind sink" verdict.

Procedure

1. Walk the app unauthenticated; record every Set-Cookie (name, attributes, source endpoint).
2. Authenticate (every auth tier: anon, low-priv user, high-priv user) and record the full cookie jar after each.
3. For each candidate sink (parameter, route, header, body field):
   • Probe with NO cookies.
   • Probe with FULL authenticated jar.
   • Bisect: drop one cookie at a time and re-probe. The cookie whose removal silences the sink is the gating cookie.
4. Document a "Sink preconditions" table in recon_notes.md and SUMMARY.md:

4a. Session mutation audit. For every endpoint that READS session, trace which other endpoints WRITE to the SAME session key BEFORE the security verdict (login, password check, role lookup). This is the data race-condition exploit needs. Output a "Session-write timeline" table:

If the challenge tag includes race_condition, toctou, concurrent, or smuggling_desync and recon hands off WITHOUT this table, exploit MUST flag the handoff back as "recon incomplete: session-write timeline missing".

5. In the handoff to exploit/postexploit, ALWAYS include a Required session state line:

Required session state: cookies=[session, auth_tier=user]; obtained via POST /login (creds: user@example.com / hunter2)

If recon hands off without this line, exploit is required to re-run cookie enumeration before concluding any sink is unreachable.