| name | business-logic-hunter |
| description | Tests application-specific logic for workflow bypasses (skipping steps), data-validation gaps (negative prices, oversized quantities, unit confusion), hidden-field tampering, function-usage abuse (coupon reuse, free-trial re-registration), and trust-boundary pivots. Use when the target has complex multi-step workflows (checkout, account recovery, approval chains), parameters with real-world meaning (prices, quantities, dates), or state-carrying hidden fields. This class is unique to each app - requires understanding of intended business rules. Produces findings with CWE-840 / CWE-841 mapping and server-side-authoritative-validation remediation. |
| model | opus |
| allowed-tools | Read, Grep, Glob, Write(path:.claude/planning/**), WebFetch, Bash(curl:*), Bash(wget:*), Bash(httpx:*), Bash(ffuf:*), Bash(gobuster:*), Bash(nuclei:*), Bash(jq:*), Bash(arjun:*), Bash(gf:*), Bash(gau:*), Bash(waybackurls:*), Bash(nmap:--script=safe*), Bash(nmap:-sV), Bash(nmap:-Pn), Bash(dig:*), Bash(host:*), Bash(whois:*), Bash(openssl:s_client*), Bash(openssl:x509*)
|
| metadata | {"version":"1.0.0","category":"security-testing","subcategory":"logic","authorization_required":true,"tier":"T1","source_methodology":"Guia de Vulnerabilidades em Lógica de Negócios.md","service_affecting":false,"composed_from":[]} |
Business Logic Hunter
Goal
Test application-specific logic for flaws that arise from violated
developer assumptions - workflow bypasses, logically-invalid-but-
technically-valid data (negative prices, oversized quantities,
unit-confusion), hidden-field tampering, function-usage abuse (coupon
reuse), and trust-boundary pivots (recovery flow granting login-like
state). Unlike technical vulnerabilities, logic flaws are unique to
each application and require context. This skill implements WSTG-BUSL
and maps findings to CWE-840 (Business Logic Errors) and CWE-841
(Improper Enforcement of Behavioral Workflow). The goal is to hand
the product + backend team a concrete list of workflow and
data-validation gaps with server-side-authoritative remediation.
When to Use
- The target has complex multi-step workflows: checkout, account
recovery, approval chains, subscription changes, multi-party
transactions.
- Parameters encode real-world meaning: prices, quantities,
currency codes, dates, units, tenure.
- Hidden form fields or API properties carry state that could be
tampered (
user_role, price, approvalStatus, step).
- One-time / limited-use functions exist: coupon codes, free-trial
eligibility, referral rewards, one-per-household offers.
- Data "hand-off" points exist between systems (e.g., inventory
system → pricing → checkout) that may trust each other.
- The orchestrator selects this skill after
api-recon surfaces
workflow inventory.
When NOT to Use
- For generic input-validation flaws (SQLi, XSS, command injection)
- use the class-specific hunter.
- For missing access control (user reaching another user's data) - use
idor-hunter / bola-bfla-hunter.
- For mass-assignment / admin-flag injection in generic
profile-update endpoints - use
mass-assignment-hunter.
- For rate-limit-specific abuse (e.g., SMS cost amplification,
brute-force) - use
rate-limit-hunter.
- Any asset not listed in
.claude/security-scope.yaml or whose
testing_level is not active.
Authorization Check (MANDATORY FIRST STEP)
Before ANY outbound activity:
- Read
.claude/security-scope.yaml. If the file doesn't exist or
doesn't parse, halt and report.
- Confirm the intended target appears in the
assets list AND its
testing_level is active.
- Business-logic testing triggers real workflow actions: creating
orders, using coupons, consuming trial offers. Use ONLY:
- Test accounts and test billing instruments (test credit cards,
test SMS numbers from the scope)
- Reversible actions (cancel the order immediately after
creation; consume test coupons that have no real value)
- For financial-impact findings (negative price, oversized credit,
coupon-reuse): STOP at the first confirmation. Do NOT escalate
to see "how much" can be stolen - one proof is enough.
Coordinate revert with the platform team.
- For workflow-bypass findings that create persistent records
(KYC-skip, approval-skip), file the finding AND request that
the record be cleared from the production DB.
- Log the authorization check to
.claude/planning/{issue}/SECURITY_AUDIT.md Skills Run Log with
status running.
Inputs
The skill expects the caller to provide:
{issue}: the planning folder name{target}: the asset identifier from security-scope.yaml{scope_context}: the workflows to test (e.g., "checkout",
"account-recovery", "subscription-change"){user_a}: test-user credentials{user_b}: second test-user credentials (for cross-user logic
tests){test_billing}: test credit-card / payment instrument from scope{workflow_docs}: optional - links to product-team
documentation describing intended workflows
Methodology
Phase 1: Workflow Mapping
-
Trace the target workflow end-to-end [Hacking APIs, Ch 7, p. 166]
Do: Execute the workflow once as {user_a} through the UI / API
with all steps completed normally. Capture every HTTP request:
method, path, request body, response status, state carried
forward.
Record: .claude/planning/{issue}/workflow-traces/{workflow}/happy-path.har
and a human-readable summary in
.claude/planning/{issue}/workflow-traces/{workflow}/summary.md.
-
Identify state-carrying parameters [WAHH, Ch 11, p. 410]
Do: For each step, identify what state is carried forward:
- Session cookies or JWTs (handled by
session-flaw-hunter /
jwt-hunter)
- Explicit
step / stage / phase parameters in URLs or
bodies
- Hidden form fields (
<input type="hidden" name="price" value="10">)
- URL parameters encoding state (
/checkout?amount=10.00& currency=USD)
- Referer-based navigation logic
Record: State-inventory matrix per workflow.
Phase 2: Workflow Bypass
-
Step-skipping probe
[WSTG v4.2, WSTG-BUSL-06]
Do: Execute the workflow up to step N, then skip to step N+2
(or the final "success" step) directly. Try:
- Directly GET / POST to the URL of step N+2 without completing
step N+1
- Submit a step-N+2 request with state captured from step N
(not N+1)
- Replay step N's response-provided redirect-URL but with a
later step's expected body
Vulnerable response: The application treats the workflow as
completed - e.g., the user gets an "order confirmed" page
without payment processed.
Not-vulnerable response: The server rolls back, redirects to
the missing step, or returns 403.
Record: Per-skip FINDING-NNN.
-
Out-of-order step probe
[WAHH, Ch 11]
Do: Submit step N+1 BEFORE step N.
Vulnerable response: Step N+1 processes using incomplete state
(e.g., placing an order before adding items to cart).
Record: Findings.
Phase 3: Logical Data Validation
-
Negative / zero / boundary values
[WSTG v4.2, WSTG-BUSL-01]
Do: For fields representing quantities, prices, durations,
unit counts, try:
- Negative:
-1, -100, -999999
- Zero:
0
- Very large:
999999999999
- Non-integer where integer expected:
1.5 for a count
- Unicode numeric characters:
١٢٣ (Arabic), 一二三 (Chinese)
For price specifically, a negative price can result in a
NEGATIVE charge (refund) at checkout.
Vulnerable response: The app accepts and applies the logically-
invalid value.
Not-vulnerable response: 400 Bad Request with range validation
error.
Record: Per-field FINDING-NNN.
-
Unit / currency confusion
[WAHH, Ch 11]
Do: For pricing or measurement endpoints, try:
- Submit price in a different currency than expected (e.g.,
{"price": 100, "currency": "IDR"} when the backend
assumes USD)
- Submit weight in ounces where the backend assumes grams
- Submit prices with different decimal conventions (12.50 vs
12,50)
Vulnerable response: The server uses the submitted currency /
unit without re-validation against the user's region or the
product's defined currency.
Record: FINDING-NNN - often leads to 100x or 1000x price
errors.
Phase 4: Hidden-Field Tampering
-
Edit-hidden-fields probe
[WSTG v4.2, WSTG-BUSL-03]
Do: For each hidden form field or state-carrying URL / body
parameter identified in Phase 1:
- Flip booleans:
hasPaid=false → hasPaid=true;
approvalRequired=true → false
- Change numerics:
price=10.00 → price=0.01;
quantity=1 → quantity=1000
- Change references:
cartId={yours} →
cartId={other_user's} (cross-reference idor-hunter)
- Toggle feature flags:
debug=false → debug=true;
adminMode=false → true
Vulnerable response: The tampered field is honored server-side.
Not-vulnerable response: Server rejects or recomputes from
trusted backend state.
Record: Per-field FINDING-NNN.
Phase 5: Function-Usage Abuse
-
One-time-function reuse [WSTG v4.2, WSTG-BUSL-05]
Do: For functions documented as one-per-user or one-per-session:
- Coupon codes: redeem the same code twice
- Free-trial: sign up for the trial with the same email /
phone / device
- Referral bonus: claim a referral reward twice for the same
referrer-referee pair
Vulnerable response: Function executes multiple times - often
leading to direct financial impact or resource exhaustion.
Not-vulnerable response: Second invocation rejected.
Record: Per-function findings.
-
Race condition on one-time functions
[WAHH, Ch 11]
Do: Send 5-10 parallel requests for the SAME one-time function
(same coupon code, same referral claim) using low-concurrency
but simultaneous start times. Some race-prone implementations
check the single-use flag AFTER processing, letting parallel
requests all succeed.
Vulnerable response: More than one parallel request succeeded.
Not-vulnerable response: Exactly one succeeded, the rest
rejected.
Record: Parallelism-count where the defense still held.
Phase 6: Trust-Boundary Pivoting
-
Partial-auth state pivoting
[WAHH, Ch 21, p. 844]
Do: Start a flow that grants partial trust (account-recovery,
email-verification, SSO-callback, invite-link). Before
completing it, try to use the partial-trust state to access
full-auth resources.
Example: Account-recovery sends an email with a "continue
reset" link. Open the link but don't set a new password.
Instead, try to access /account/settings directly - does
the partial-recovery session grant it?
Vulnerable response: Partial-trust state lets the user access
full-auth scope.
Not-vulnerable response: Full-auth endpoints require a
completed login, not a recovery-initiated session.
Record: Per-flow FINDING-NNN.
-
Cross-system hand-off trust
[WAHH, Ch 21]
Do: If the app has hand-off points (payment redirect from a
third-party processor, SSO callback, webhook from an internal
service), try to mimic the hand-off callback with tampered
parameters.
Example: If payment success is confirmed via a
/payment-callback?orderId=X&status=success URL, try
manually visiting the URL without actually paying.
Vulnerable response: Order marked paid without real payment.
Not-vulnerable response: Server validates the callback via a
signed token or IP whitelist.
Record: Cross-reference ssrf-hunter for webhook-SSRF
variants.
Payload Library
Categories:
- Workflow-step jumps:
/auth/success, /checkout/confirm,
/step3, /complete
- Logical-invalid numerics:
-1, 0, 999999999999, 1.5,
unicode digits
- State-flag flips:
hasPaid=true, mfa=false, admin=true,
approvalRequired=false
- Cross-currency confusion: different
currency codes paired
with original price values
- Parallel one-time probes: 5-10 concurrent requests for the
same single-use operation
- Trust-pivot probes: partial-auth session + direct
full-auth URL
Output Format
Findings append to .claude/planning/{issue}/SECURITY_AUDIT.md per
the schema in .claude/skills/_shared/finding-schema.md.
Specific to this skill:
- CWE: CWE-840 (Business Logic Errors). CWE-841 (Improper
Enforcement of Behavioral Workflow) for step-skipping.
CWE-20 (Improper Input Validation) for logical-invalid data.
CWE-837 (Improper Enforcement of Single, Unique Action) for
one-time-function reuse.
- OWASP: WSTG-BUSL-01 through WSTG-BUSL-09. For APIs,
API6:2023 (Unrestricted Access to Sensitive Business Flows).
A04:2021 (Insecure Design) for design-level gaps.
- CVSS vectors: direct financial theft -
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N. Step-skip bypassing
payment - ...PR:L/C:N/I:H/A:N. Coupon reuse at scale - ...AC:L/C:N/I:L/A:N (aggregated financial impact, not per-user
severity).
- Evidence: the workflow HAR (normal path), the tampered
request, the server response, and the resulting state change
(order with $0 total, free trial granted twice, etc.).
- Remediation framing: backend engineer + product. Include:
- Server-side authoritative state (don't trust client
step=complete)
- Transactional rollback (entire workflow commits or rolls
back atomically)
- Input range validation (min/max per field, including
logical constraints)
- Canonical-value server lookup (price from product table,
not client request)
- Idempotency keys + DB-level unique constraints for
one-time functions
- HMAC-signed callback parameters for cross-system hand-offs
The skill also updates:
.claude/planning/{issue}/STATUS.md - its row under Phase 7: Security.claude/planning/{issue}/SECURITY_AUDIT.md Skills Run Log
Quality Check (Self-Review)
Before marking complete, verify:
Common Issues
-
Uniform success with embedded error: The server returns 200
for out-of-order requests but the body contains "Please complete
step N+1 first". Automated tools misread. Always check response
body.
-
Client-side-only enforcement: A GUI-level price manipulation
appears to work in the browser, but the server bills the original
price during final processing. Confirm with a server-side GET
of the completed transaction.
-
Race-condition false negatives: Single-attempt tests may
succeed due to timing. Re-run race-condition tests 3 times; the
bug may only manifest under specific concurrency patterns.
-
Coupon-reuse as intended behavior: Some coupons are
legitimately multi-use (site-wide codes, recurring subscriber
rewards). Check product docs / admin UI before filing - the
defect is "one-per-user" codes being reused, not all coupons.
-
Partial-trust pivot that's actually intended: Password-reset
flows legitimately grant a narrow session to set a new password.
The bug is when that session also grants unrelated full-auth
scope. Distinguish by checking what the partial session is
authorized to do - if it's scoped to password-reset only, the
flow is correct.
-
Negative-price that refunds to original payer, not attacker:
A negative-quantity bug may result in an inventory error
(stock increments) without financial impact because the
negative charge is refunded to the payer, not the attacker.
Still a finding - operations risk, inventory fraud - but lower
severity than direct theft.
References
External:
Source Methodology
Converted from:
pentest-agent-development/notebooklm-notes/Guia de Vulnerabilidades em Lógica de Negócios.md
Grounded in:
- The Web Application Hacker's Handbook, Ch 11 (Attacking
Application Logic) + Ch 21 (Exploit Chaining)
- Hacking APIs, Ch 7 (Endpoint Analysis)
- OWASP WSTG v4.2 (Section 4.10)
- Bug Bounty Bootcamp, Ch 17-18 (Logic Bypasses)
Conversion date: 2026-04-24
Conversion prompt version: 1.0
