hunt-business-logic

name	hunt-business-logic
description	Hunting skill for business logic vulnerabilities. Built from 12 public bug bounty reports. Covers coupon-race-stacking (Instacart, Stripe, Reverb), negative-quantity-in-cart price tampering (Upserve, Eternal/Zomato), decimal/fraction price-field overflow (Shipt), client-side checkout amount trust on PayPal redirect (WordPress.org), price-per-unit mass-assignment (Krisp), and archived-price swap / cart-TOCTOU (Stripe). Use when hunting business logic — heavy emphasis on financial-impact-demonstrated cases.
sources	hackerone_public, github
report_count	12

Crown Jewel Targets

Business logic vulnerabilities pay highest in platforms where financial transactions, identity verification, and access controls intersect with real-world consequences. The richest targets are:

• E-commerce & payment platforms (Valve/Steam, Shopify) — payment flow manipulation, free goods, price tampering
• Marketplace & gig economy apps (Airbnb, Uber) — identity/verification bypass enabling fraud or unsafe interactions
• SaaS with tiered access (Mozilla Monitor) — bypassing verification to unlock monitoring features without entitlement
• High-traffic consumer apps (Snapchat, Yelp) — rate-limit bypass enabling spam, enumeration, or abuse at scale

Asset types that pay: checkout flows, subscription endpoints, callback/verification systems, webhook handlers, employee/internal portals exposed to the internet, and any endpoint that trusts client-supplied data to make authorization decisions.

---

Attack Surface Signals

URL patterns to watch:

• /checkout, /order, /subscribe, /payment, /verify, /confirm, /callback
• /internal, /employee, /summit, /staff, /admin — internal pages accidentally public
• /api/v*/payment, /api/v*/notify, /webhook — payment provider callbacks
• Endpoints accepting X-Forwarded-For, X-Real-IP, CF-Connecting-IP headers

Response/header signals:

• Set-Cookie with unvalidated session state tied to cart or order data
• Payment provider names in responses: Smart2Pay, Stripe, PayPal, Braintree
• Redirect chains through third-party payment pages (in-flight data opportunity)
• 200 OK on subscription/verification endpoints with no CAPTCHA or token

JS patterns:

• Hardcoded internal URLs in frontend bundles (/employee/, /staff/, /internal/)
• Client-side price calculation before server submission
• Verification logic that only checks on the frontend (if (verified) { ... })
• fetch('/api/subscribe', { method: 'POST', body: ... }) with no anti-CSRF token or rate-limit token

Tech stack signals:

• Shopify storefronts with draft/unpublished channel pages
• Apps using IP-based rate limiting without session/account binding
• Payment webhooks with no HMAC signature validation
• SMS/phone callback flows that don't verify ownership before enabling features

---

Step-by-Step Hunting Methodology

1. Map all authentication boundaries. Spider the target. Identify pages/endpoints that serve authenticated content (employee portals, premium features, order pages) and test each unauthenticated. Look for internal pages indexed in JS bundles or linked from robots.txt/sitemap.xml.

2. Identify every verification flow. Enumerate: email verification, phone/SMS verification, payment verification, CAPTCHA, age gates. For each, test: what happens if you skip the verification step entirely? What happens if you replay a valid token on a different account?

3. Test rate-limiting controls on every form. For every POST endpoint (subscribe, login, OTP, search), send 50+ rapid requests. Vary: remove cookies, rotate X-Forwarded-For / X-Real-IP headers, change User-Agent. Check if the server uses IP from headers rather than connection IP.

4. Intercept and tamper with payment flows. Use Burp Suite to intercept every request between your browser, the application, and the payment provider. Identify where price, currency, order ID, or status fields are set. Attempt to modify amounts to $0.01 or currency to a low-value currency. Look for POST-back/webhook endpoints that accept payment confirmation — test if they validate HMAC/signature.

5. Test phone/callback number verification. Whenever a platform accepts a callback number, test: can you set it to a number you don't own? Does the platform call/text that number and grant trust based solely on submission? Try setting it to a victim's number.

6. Check for unprotected employee/internal surfaces. Search Shodan, GitHub, JS bundles, and Wayback Machine for internal subdomain/path references. Test access without authentication. Check if these surfaces allow order placement, data access, or privilege escalation.

7. Validate business impact. For each finding, determine: does this result in financial loss, unauthorized access, or data exposure? Document the end-to-end chain.

---

Payload & Detection Patterns

Rate limit bypass via header rotation:

# Rotate X-Forwarded-For to bypass IP rate limiting
for i in $(seq 1 100); do
  curl -s -X POST https://target.com/api/subscribe \
    -H "X-Forwarded-For: 10.0.0.$i" \
    -H "X-Real-IP: 10.0.0.$i" \
    -H "Content-Type: application/json" \
    -d '{"email":"victim+'"$i"'@example.com"}' \
    -o /dev/null -w "%{http_code}\n"
done

Payment tampering — modify in-flight price:

POST /payment/initiate HTTP/1.1
Host: target.com

amount=0.01&currency=USD&order_id=12345&product_id=99

# Look for unvalidated webhook endpoints
curl -X POST https://target.com/payment/callback \
  -H "Content-Type: application/json" \
  -d '{"status":"success","amount":"0.01","order_id":"12345","transaction_id":"fake-txn"}'

Unauthenticated internal page discovery:

# Check robots.txt and sitemap for internal paths
curl -s https://target.com/robots.txt | grep -iE "(disallow|allow)" 
curl -s https://target.com/sitemap.xml | grep -iE "(employee|internal|staff|summit|admin)"

# Grep JS bundles for internal paths
curl -s https://target.com/assets/app.js | grep -oE '"/[a-zA-Z0-9/_-]{3,50}"' | sort -u

Email verification bypass:

# Skip the verification step: hit the post-verification API endpoint directly
# with an unverified session. If it succeeds, the gate is UI-only.
curl -s -X POST https://monitor.target.com/api/monitoring/enable \
  -H "Cookie: session=<your_unverified_session>" \
  -H "Content-Type: application/json" \
  -d '{"email":"[e-mail]"}'

# Replay verification token on different account
curl -X POST https://target.com/verify \
  -d 'token=VALID_TOKEN_FROM_ACCOUNT_A&email=[e-mail]'

Grep patterns for client-side logic issues:

# Find price calculations in JS
grep -iE "(price|amount|total|cost)\s*[=*+]" app.js

# Find internal URLs in JS bundles
grep -oE '"/(employee|internal|staff|admin|summit)[^"]*"' *.js

# Find unvalidated IP header usage in server code
grep -iE "x-forwarded-for|x-real-ip|cf-connecting-ip" src/ -r

---

Common Root Causes

1. Server trusts client-supplied data for financial decisions. Developers offload price calculation to the frontend or pass amount fields through forms/URLs without re-validating on the server against a canonical source (the product database).

2. Verification is enforced only in the UI, not the API. Frontend hides features behind a verification gate, but the backend API endpoints are fully functional without a verified status — any authenticated request succeeds.

3. IP-based rate limiting reads from spoofable headers. Developers implement rate limits using request.headers['X-Forwarded-For'] instead of the actual connection IP, allowing trivial bypass by header manipulation.

4. Payment webhooks lack signature validation. Developers implement "success" webhooks without verifying the HMAC signature provided by the payment provider, allowing anyone to POST a fake success notification.

5. Internal/employee pages aren't access-controlled. Internal tools are deployed to production domains without authentication middleware, either because developers assume obscurity (unlisted URL) or forgot to apply auth to a new route.

6. Phone/callback verification is advisory, not enforced. Systems accept a phone number and grant trust to whoever submitted it, without confirming the submitter owns or controls that number.

7. Draft/channel-specific storefronts inherit full order functionality. Platforms like Shopify allow creating storefronts for specific channels (employee events) that are unlisted but still fully functional for order placement if the URL is known.

---

Bypass Techniques

Defense	Bypass
IP-based rate limiting	Rotate X-Forwarded-For, X-Real-IP, True-Client-IP, CF-Connecting-IP headers per request
CAPTCHA on subscription forms	Use header-based bypass first; if CAPTCHA is only on the web form, call the underlying API endpoint directly
Email verification gate	Access the post-verification API endpoint directly; replay valid tokens; check if verified=true is a client-set cookie/param
Payment amount server validation	Modify currency to a lower-value currency; test with $0.00 or negative amounts; manipulate order IDs to reference different products
Webhook HMAC validation	Test with no/empty signature header (is validation enforced at all — a modified payload only "passes" if it isn't); replay an UNMODIFIED captured webhook to test missing idempotency/anti-replay
Auth on internal pages	Try unauthenticated; try with a low-privilege account; try path traversal variants (/employee/../employee/)
Phone verification (OTP sent)	Submit someone else's number without OTP validation; check if the system grants trust on submission vs. OTP confirmation

---

Gate 0 Validation

Before writing any report, answer all three:

1. What can the attacker DO right now? Be specific: "An unauthenticated user can place an order for physical goods at $0 cost" or "An attacker can bypass email verification and monitor any email address without owning it" or "An attacker can send unlimited subscription emails to any address." Vague impact = reject.

2. What does the victim LOSE? Identify a concrete, attributable loss: financial loss (free goods, fraudulent payments), privacy loss (phone number spoofed, unauthorized monitoring), service abuse (spam campaigns via rate-limit bypass), or security degradation (unverified identity trusted for sensitive actions). If the loss is purely theoretical, re-evaluate severity.

3. Can it be reproduced in 10 minutes from scratch? Create a fresh account (or use no account). Follow your documented steps. Achieve the impact. If you can't reliably reproduce it end-to-end in under 10 minutes with the steps you've written, your methodology is incomplete — refine before submitting.

---

Real Impact Examples

Scenario 1 — Free Physical Goods via Exposed Internal Storefront (Shopify-style) An employee summit page was deployed to a public Shopify storefront as a private channel for distributing free books to staff. The URL was discoverable via JS bundle analysis or link sharing. An anonymous user who navigated to the URL could browse and complete a checkout with no authentication required, receiving physical merchandise shipped at the company's expense. Impact: direct financial loss per order, potential for bulk ordering if not caught quickly.

Scenario 2 — Payment Manipulation via In-Flight Tampering (Valve/Steam-style) A payment flow passed order amount and currency through client-controlled parameters before redirecting to a third-party payment provider (Smart2Pay). By intercepting the redirect with Burp Suite and modifying the amount field, an attacker could complete a real payment for $0.01 while the application's webhook — lacking HMAC validation — accepted the provider's confirmation and credited the full item/service to the account. Impact: critical financial loss; attacker receives full value goods/services for near-zero cost, infinitely repeatable.

Scenario 3 — Email Verification Bypass for Unauthorized Monitoring (Mozilla-style) A breach-monitoring service required email verification before enabling monitoring alerts for an address. The verification check was enforced in the UI flow but the underlying API accepted monitoring setup requests for any address using a valid session — skipping the verification step entirely. An attacker could set up monitoring for email addresses they don't own, receiving breach notification data (potentially including credential exposure status) for victim accounts. Impact: privacy violation; attacker gains intelligence on whether a target's email was in a breach without the target's knowledge or consent.

---

Disclosed Report Citations (Backfill +5 — 2016-2023)

The following real, verified bug-bounty / coordinated-disclosure cases extend this skill. All five share a measurable financial-impact angle (actual $ loss demonstrated or quantifiable platform-wide exposure).

8. Stripe — Fee discount race redemption (H1 #1849626)

   • Subclass: coupon/discount race-multi-redemption + financial primitive
   • Payload: Stripe Support applied a one-time $20,000 fee-credit. Researcher captured the "accept-discount" POST and replayed it 30× in parallel via Burp Turbo Intruder, each acceptance crediting the account anew
   • Root cause: idempotency missing on discount-acceptance endpoint; no unique constraint on (account_id, discount_id)
   • Year: 2023 — $5,000, $600,000 of fee-free transactions accrued before fix (~$18,000 real Stripe loss at 3% take rate)

9. Reverb.com — Gift-card race multi-redemption (H1 #759247)

   • Subclass: gift-card / store-credit race-redemption
   • Payload: single valid gift card, parallel-POST to /redeem from 10 sockets via Turbo Intruder. Balance credits N× the face value
   • Root cause: no row-level lock on gift_card table; balance debit and credit live in separate transactions
   • Year: 2019 — $1,500

10. Upserve / OLO — Negative-quantity price manipulation (H1 #364843)

    • Subclass: negative-quantity-in-cart price tampering
    • Payload: POST /api/order {"items":[{"id":1,"qty":1,"price":50},{"id":2,"qty":-3,"price":50}]} — order total computes to -$100, floors to ~$0 at payment capture, food still fulfills
    • Root cause: server multiplies qty * price with no qty >= 1 guard
    • Year: 2018 — textbook citation for the subclass (acknowledged-only program)

11. Krisp — Pay-less-per-seat via PUT tampering (H1 #1446090)

    • Subclass: price-per-unit mass-assignment / quantity-discount manipulation
    • Payload: PUT /v2/seats body includes a server-trusted price field. Set price=1 instead of $60. Subscription updates, billing engine charges $1/seat for 100 seats
    • Root cause: server reads price from request body instead of looking it up by plan_id; classic mass-assignment
    • Year: 2021 — Stripe-billed SaaS pricing exposure

12. Stripe — Pay using archived price via mid-flow swap ()

---

Related Skills & Chains

• hunt-race-condition — Every uniqueness/quota check in a logic flow is a race candidate. Chain primitive: Business logic (coupon/credit/promotion) + race condition → coupon redeemed N times in a single TCP packet via Turbo Intruder.
• hunt-idor — Logic flows that trust a client-supplied identifier (order_id, tenant_id, beneficiary_id) overlap directly with IDOR. Chain primitive: business-logic step-skip + IDOR on beneficiary_id → transfer funds from victim account.
• hunt-api-misconfig — Step-skip and verification-bypass often live next to mass-assignment fields. Chain primitive: business-logic email-verify skip + API mass assignment (verified:true, role:admin) → ATO without email control.
• hunt-ato — Logic bugs in password reset, email change, and recovery flows are core ATO paths. Chain primitive: business logic (email change accepts without re-auth) + hunt-ato Path 2 → silent victim email swap → password reset to attacker mailbox.
• security-arsenal — Load the Business-Logic Probe Checklist (negative quantity, decimal overflow, currency swap, step-skip via direct URL nav, state-machine reverse) and the Always-Rejected list to avoid filing self-inflicted bugs.
• triage-validation — Apply the 7-Question Gate (especially Q4 "Is this exploitable by an outside attacker without unrealistic preconditions?"): logic bugs need a concrete dollar/PII/state impact, not just "the flow looks weird".

---

Price Tampering — Client-Side Trust Pattern

The #1 business logic pattern in SaaS: the server trusts the price field from the client request body. The client sends "price":0 and the server creates a checkout session at R$0 instead of looking up the product price from the database.

Detection

# 1. Create a purchase with normal flow, capture the request
# 2. Replay with modified price
curl -sk -X POST "https://api.target.com/checkout" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"items":[{"id":"premium_product","quantity":1,"price":0}]}'

# 3. Test negative prices  
curl -sk -X POST "https://api.target.com/api/payments/create" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"items":[{"id":"plan","quantity":1,"price":-100}]}'

# 4. Test arbitrary quantities
curl -sk -X POST "https://api.target.com/api/checkout" \
  -d '{"items":[{"id":"key","quantity":999,"price":0}]}'

Indicators

• Checkout/payment endpoint returns a third-party payment URL (Stripe, Asaas, MercadoPago)
• The payment URL has cs_test_ prefix (Stripe test mode — payment not actually processed)
• Server responds with purchase ID + checkout URL regardless of price value
• Product prices visible in JS bundle but never cross-referenced server-side

Verification

• Confirmed: Checkout URL created at R$0, payment page loads showing R$0.00
• Confirmed critical: Purchase completed at R$0, license/key granted
• False positive: Server rejects with "price mismatch" or uses server-side price lookup

Related

• hunt-write-gap — When price tampering succeeds because the server PATCH/POST endpoint lacks validation
• hunt-supabase — PostgREST accepting any value for price fields via anon key