No test for multi-step business flows (e.g. password-reset-for-another-user)

Summary

Found while tracing ASTF's findings against crAPI's documented vulnerabilities. crAPI documents resetting another user's password as a challenge, requiring: (1) discover or guess a victim's email, (2) trigger the password-reset flow for that email, (3) intercept/guess the reset token (crAPI is known for weak/predictable OTP-style reset tokens in some versions), (4) submit a new password with that token.

Root cause

Every existing ASTF test case is a single-request (or single-request-pair, for the new cross-user BOLA check in #87) check: send a request, inspect the response. There's no capability for a multi-step, stateful flow where step N's response feeds step N+1's request — which is exactly the shape of most real password-reset, email-verification, and OTP-based vulnerabilities.

Suggested fix

This is a larger architectural addition, not a small fix, and worth scoping deliberately rather than bolting onto an existing test case:

• A test case (or small framework capability) that can chain 2-4 requests, where a value from one response (a reset token, a temporary ID, an OTP) is extracted and reused in the next request.
• For the specific crAPI-style scenario: trigger a password reset for a different user than the current identity, then attempt to guess/brute-force a short numeric OTP or predictable token within a bounded attempt count, and confirm whether the new password takes effect.

Given the scope, this is filed as a distinct architectural enhancement rather than folded into an existing test case — it likely needs its own design discussion about how chained/stateful requests should work across the framework, since other multi-step flows (email verification, OTP-based MFA, etc.) would benefit from the same capability.

Found during a coverage traceback pass cross-referencing ASTF's actual scan output against crAPI's own documented vulnerability list.

Start by reviewing ASTF's existing single-request test cases and the cross-user BOLA check in #87 to understand the current testing model. Then scope a design for chained, stateful requests using the password-reset flow as the example; done means the framework capability and its boundaries are agreed for reset, email-verification, and OTP flows.