hunt-business-logic – Security skill for AI agents

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Crown Jewel Targets

Business logic vulnerabilities can cause serious harm in platforms where financial transactions, identity verification, and access controls intersect with real-world consequences. Relevant authorized application categories include:

• 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

Relevant asset types: 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), use a tiny owner-approved request budget with controlled test accounts and stop on 429/lockout/errors; never infer safety from a fixed request count. In a sandbox, compare trusted proxy handling of 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. Use a provider sandbox and synthetic products/orders with fulfillment, billing and notifications disabled; compare price/currency/order binding without real financial transactions. 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? Use only two owner-controlled test numbers with prior consent; never cause calls or messages to a victim.

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

Controlled rate-limit validation plan:

Create two synthetic test identities and a tiny preapproved cap. Compare baseline

requests to a single changed forwarding-header input in a sandbox with known trusted

proxy configuration. Confirm the server-derived limiter key; a 200 response alone

is not proof of bypass. Never send subscription email/SMS or evade an active block.

Payment tampering — modify in-flight price:

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

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

# Look for unvalidated webhook endpoints
curl -X POST https://target.example/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.example/robots.txt | grep -iE "(disallow|allow)"
curl -s https://target.example/sitemap.xml | grep -iE "(employee|internal|staff|summit|admin)"

# Grep JS bundles for internal paths
curl -s https://target.example/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. A 2xx alone is insufficient; verify the controlled account’s forbidden state transition and absence of a later server-side gate.
curl -s -X POST https://monitor.target.example/api/monitoring/enable \
  -H "Cookie: session=<your_unverified_session>" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]"}'

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

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 verific

… (full content is in the download package)