Hunt Bizlogic

Hunt: Business Logic

Assumes hunt-core for the scope gate, two-account rule, confirmation gate, enumeration limits, stop conditions, wiki protocol, FIND output, and Deadends. Do not re-derive any of that here.

Wiki

qmd_query "business logic flaw workflow state bypass price quantity tampering coupon refund race condition" via wiki-search MCP

Hub: [[web-moc]] (live index). Primary page: [[business-logic]]. Anchors: [[race-conditions]].

No scanner finds these

This is the top-paying bug class and the one with zero scanner coverage - it is all manual reasoning. Find an assumption the developer made and break it: that steps happen in order, that values are positive, that the client cannot change a field, that an action cannot be repeated. Map the intended workflow first (read the feature, the happy path, every state transition); the flaw is always the gap between that and what the server actually enforces.

Attack surface - rank before testing

Money and state-machine endpoints pay; cosmetic ones do not. Work them in this order:

1. Checkout / payment - client-supplied price, total, tax, currency, shipping, anywhere the server should recompute a value and instead trusts it.
2. Refund / coupon / gift card / store credit - re-redemption, stacking, negative amounts, a refund exceeding the purchase.
3. Multi-step workflows - checkout, transfer, signup, KYC, password reset, subscription: skip, replay, or reorder a step.
4. Quantity / price fields - negative, zero, overflow, decimal and rounding.
5. State transitions - an action valid only in one state performed from another (ship before pay, use before verify).

Methodology

Setup: two accounts per hunt-core where the flaw is cross-actor; one account suffices for pure value or state tampering. Drive the load-bearing requests through Burp Repeater for operator visibility.

1. Map the flow. Enumerate every step and state of the target feature. Note each parameter and which server check governs it. The flaw is a check the client can reach around.

2. Step / state bypass. Skip a step (POST straight to the final endpoint), replay an earlier step, run steps out of order, reuse a one-time token, reach step N without completing N-1.

3. Value tampering.

quantity = -1            # negative -> credit / refund
price / amount = 0.01    # client-supplied price
currency swap            # pay in a weaker currency, credited in a stronger one
integer overflow / very large qty
decimal / rounding (0.001 * 1000)

4. Repetition / limits / logic race. Apply a coupon twice, redeem a gift card twice, exceed a per-account limit. When the limit is a check-then-act with no lock, fire a small concurrent burst at the single endpoint (logic [[race-conditions]]) so several requests pass the check before any commits. Keep the burst bounded: a handful of parallel requests is the proof, honor no_dos, never a sustained flood. Per hunt-core this is a bounded active proof, not object enumeration, so the 5-to-20 identifier ceiling does not apply, but the RoE rate cap does. Send the request to Turbo Intruder via send_to_intruder / the Burp MCP and fire it with a single-packet or synchronized-gate script so the operator watches the race live; a hand-rolled parallel curl loop hides it.

5. Mass assignment / parameter injection. Add fields the UI never sends (isAdmin, role, balance, verified, discount, userId) to JSON or form bodies; observe a privilege or state change.

6. Trust-boundary confusion. Values the server should compute but trusts from the client (total, tax, role, KYC status, account tier); flags re-sent and re-trusted on a later request.

7. Identity / authorization logic. An action allowed for the wrong account state (an unverified user performing a verified-only action) or against another user's object (-> [[access-control]] / hunt-idor).