# Hunt Bizlogic > 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. - Skill: `encod3d-sec/hunt-bizlogic` (Agent Skill) - Install (CLI): `npx skillmds@latest add encod3d-sec/hunt-bizlogic` - Raw SKILL.md: https://api.skillmd.com/api/skills/encod3d-sec/hunt-bizlogic/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: Encod3d-Sec (https://skillmd.com/u/encod3d-sec) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/encod3d-sec/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`). ## 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 on realized impact per `hunt-core`. | Outcome | Typical | |---|---| | Direct financial theft, auth bypass, unlimited privilege | critical | | Discount / refund abuse, quota bypass with money impact | high | | Limited abuse needing preconditions | medium | ## Distill Confirmed and reusable (a generic logic-abuse pattern, no client specifics): `python3 scripts/wiki-stage.py --kind technique --slug --target-page techniques/web/business-logic.md`. ## Deadends ``` Append: - [ ] logic on -- server recomputes price/total, enforces the state machine, ignores extra fields, idempotency keys present; race lost after bounded burst ``` Record what the server enforced, so the next pass does not retest a solid boundary.