business-logic-vulnerabilities
Business logic vulnerability playbook. Use when reasoning about workflows, race conditions, price manipulation, coupon abuse, state machines, and multi-step authorization gaps.
Security Assessment
Detected risks:
About business-logic-vulnerabilities
An expert attack playbook for business-logic vulnerabilities, the flaws that automated scanners miss because they require reasoning about how an application's workflows, state machines, and pricing are supposed to behave. It is meant for authorized testing and bug-bounty work, and it emphasizes human judgement over tooling. The main file acts as a hub that routes to companion files: METHODOLOGY.md for the five-phase workflow and attack-surface matrix, CHECKLIST.md for module-by-module line items (login, register, payment, IDOR, privacy), and SCENARIOS.md for deeper dives into payment precision and overflow, captcha bypass, password reset, enumeration, and frontend bypass.
The content is organized around several vulnerability families. Price and value manipulation covers negative quantity or price, fractional-quantity zero-price abuse (0元购, paying 2% by setting skuQty to 0.02 while shipping the full item), dropping a required field to coerce a free tier, integer overflow (INT_MAX+1 wrapping negative), rounding manipulation and half-price recharge cent-rounding tricks, currency-exchange lag, and promo or discount stacking. Race conditions cover double-spend and double-redeem, per-number SMS rate-limit bypass with Turbo Intruder, multi-device concurrent VIP subscription abuse, registration and reset-token races, and claim-once limit bypasses, each rooted in non-atomic check-then-update logic. A workflow section addresses step-skipping and payment-flow bypass. Many entries come from real instructor-led cases and include the interception steps needed to reproduce them.
Practical exploitation leans on Burp Suite's parallel send-group feature and Turbo Intruder scripting for race windows, with concrete Python request-engine snippets. Because these attacks can affect payments and live balances, the playbook repeatedly cautions to coordinate before triggering overflow tests, which can crash payment services. Throughout, each bug is explained with why it works and how to fix it server-side, for example enforcing quantity as a positive integer, requiring and validating fields the client can omit, and making check-and-update operations atomic, so the offensive material doubles as guidance for defenders.
FAQ
Why can't a scanner find these bugs?
Business-logic flaws depend on how a workflow is supposed to behave, so they are scanner-invisible and require human reasoning about state machines, pricing, and authorization rather than pattern matching.
What are the companion files for?
METHODOLOGY.md holds the five-phase workflow and attack-surface matrix, CHECKLIST.md has module-by-module check items (login, register, payment, IDOR, privacy), and SCENARIOS.md drills into payment overflow, captcha bypass, password reset, and enumeration.
How are race conditions tested?
By sending many identical requests in parallel (Burp's parallel send-group or Turbo Intruder scripts) to hit the window where check-then-update is non-atomic, enabling double-spend, limit bypass, or rate-limit defeat.
What is an example of price manipulation?
Setting a fractional quantity like skuQty 0.02 so the server charges 2% of the price but ships the full item, because it multiplies unit price by quantity without enforcing a positive integer.
Are there safety considerations when testing?
Yes. Overflow and payment tests can crash live payment services, so the playbook advises coordinating before triggering them and treating balances and payments as sensitive.
Install business-logic-vulnerabilities
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
yaklang/hack-skills