/hunt-bizlogic

name: hunt-bizlogic
description: Business-logic flaw hunting - workflow/state bypass, price/quantity tampering, negative/overflow values, coupon/refund abuse, mass assignment, and logic races. The top-paying bug class with no scanner coverage. Wiki-first, FIND schema output.

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`).

When the value is rejected

A rejected tamper is not a closed door. Retry the same value in a representation the server parses but the validator missed: an alternate field the server also reads, parameter pollution (`price=10&price=0.01`), a nested wrapper (`{"item":{"price":0.01}}`), a type change (string vs number, array vs scalar), sign and precision tricks (`-0`, `1e-2`, trailing decimals), or re-sending a server-computed field an earlier step trusted. Reorder the steps so validation runs before the value is set.

Chaining

Logic flaws compound. A price or quantity tamper that touches *another user's* cart is logic + IDOR (hand off to `hunt-idor`); a coupon or limit bypass that only works under concurrency is logic + race ([[race-conditions]]). Chain them for higher impact and say so in the title - "race-condition coupon re-redemption" reads bigger than "coupon bug".

Confirmation gate

**NOT confirmation:** the app accepted an odd value; a `200` on a tampered request; the tampered field echoed back in the response; an order or total that merely *displays* wrong on your screen; a coupon that "applied" without the charge changing.

**IS confirmation:** the unintended end-state is realized and verified downstream - a negative or inflated balance that persists, a purchase completed at the free or discounted price (order confirmed, payment captured at the tampered amount), a workflow step skipped **and** its downstream effect confirmed (account provisioned, funds moved, access granted). For a race, the limit is actually exceeded (two redemptions both settled). Re-verify in a clean session, and confirm from the state only the successful abuse produces, not from the request the server merely accepted.

Severity

Rated