Back to Details

hunt-business-logic

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
在涉及金融交易、身份验证和访问控制且具有实际影响的平台中，业务逻辑漏洞的赏金最高。最具价值的目标包括：
  • 电商与支付平台（Valve/Steam、Shopify）——支付流程操纵、免费获取商品、价格篡改
  • 市场与零工经济应用（Airbnb、Uber）——身份/验证绕过，引发欺诈或不安全交互
  • 分层访问权限的SaaS（Mozilla Monitor）——绕过验证，无需授权即可解锁监控功能
  • 高流量消费应用（Snapchat、Yelp）——速率限制绕过，实现大规模垃圾信息发送、枚举或滥用
具有价值的资产类型包括：结算流程、订阅端点、回调/验证系统、Webhook处理器、暴露在公网的员工/内部门户，以及任何依赖客户端提供数据做出授权决策的端点。

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
需关注的URL模式：
  • /checkout
    、
    /order
    、
    /subscribe
    、
    /payment
    、
    /verify
    、
    /confirm
    、
    /callback
  • /internal
    、
    /employee
    、
    /summit
    、
    /staff
    、
    /admin
    ——意外公开的内部页面
  • /api/v*/payment
    、
    /api/v*/notify
    、
    /webhook
    ——支付服务商回调端点
  • 接受
    X-Forwarded-For
    、
    X-Real-IP
    、
    CF-Connecting-IP
    请求头的端点
响应/请求头信号：
  • Set-Cookie
    中包含与购物车或订单数据绑定且未验证的会话状态
  • 响应中出现支付服务商名称：
    Smart2Pay
    、
    Stripe
    、
    PayPal
    、
    Braintree
  • 第三方支付页面的重定向链（存在中途篡改数据的机会）
  • 订阅/验证端点返回
    200 OK
    且无CAPTCHA或令牌验证
JS模式：
  • 前端包中硬编码的内部URL（
    /employee/
    、
    /staff/
    、
    /internal/
    ）
  • 提交到服务器前在客户端计算价格
  • 仅在前端进行验证的逻辑（
    if (verified) { ... }
    ）
  • 无反CSRF令牌或速率限制令牌的
    fetch('/api/subscribe', { method: 'POST', body: ... })
    请求
技术栈信号：
  • 包含草稿/未发布渠道页面的Shopify店铺
  • 使用基于IP的速率限制但未绑定会话/账户的应用
  • 未验证HMAC签名的支付Webhook
  • 在启用功能前未验证号码所有权的SMS/电话回调流程

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.
  1. 映射所有认证边界。爬取目标站点，识别提供认证内容的页面/端点（员工门户、高级功能、订单页面），并在未认证状态下逐一测试。查找JS包中索引或robots.txt/sitemap.xml中链接的内部页面。
  2. 识别所有验证流程。枚举：邮箱验证、电话/SMS验证、支付验证、CAPTCHA、年龄验证。针对每个流程测试：完全跳过验证步骤会发生什么？在不同账户上重放有效令牌会发生什么？
  3. 测试所有表单的速率限制控制。针对每个POST端点（订阅、登录、OTP、搜索），发送50+次快速请求。尝试：移除Cookie、轮换
    X-Forwarded-For
    /
    X-Real-IP
    请求头、修改
    User-Agent
    。检查服务器是否使用请求头中的IP而非连接IP。
  4. 拦截并篡改支付流程。使用Burp Suite拦截浏览器、应用与支付服务商之间的所有请求。确定价格、货币、订单ID或状态字段的设置位置。尝试将金额修改为$0.01或切换为低价值货币。查找接受支付确认的回调/Webhook端点——测试是否验证HMAC/签名。
  5. 测试电话/回调号码验证。每当平台接受回调号码时，测试：能否设置为非本人所有的号码？平台是否仅根据提交就拨打电话/发送短信并给予信任？尝试设置为受害者的号码。
  6. 检查未受保护的员工/内部接口。在Shodan、GitHub、JS包和Wayback Machine中搜索内部子域名/路径引用。测试未认证状态下的访问权限。检查这些接口是否允许下单、数据访问或权限提升。
  7. 验证业务影响。针对每个发现，确定：是否会导致财务损失、未授权访问或数据泄露？记录完整的攻击链。

Payload & Detection Patterns

payload与检测模式

Rate limit bypass via header rotation:
bash
undefined
通过请求头轮换绕过速率限制：
bash
undefined

Rotate X-Forwarded-For to bypass IP rate limiting

轮换X-Forwarded-For以绕过IP速率限制

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:**
```http
POST /payment/initiate HTTP/1.1
Host: target.com

amount=0.01&currency=USD&order_id=12345&product_id=99
bash
undefined
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

**支付篡改——中途修改价格：**
```http
POST /payment/initiate HTTP/1.1
Host: target.com

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

Look for unvalidated webhook endpoints

查找未验证的Webhook端点

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:**
```bash
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"}'

**未认证状态下发现内部页面：**
```bash

Check robots.txt and sitemap for internal paths

检查robots.txt和sitemap中的内部路径

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)"
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

在JS包中查找内部路径

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

**Email verification bypass:**
```bash
curl -s https://target.com/assets/app.js | grep -oE '"/[a-zA-Z0-9/_-]{3,50}"' | sort -u

**邮箱验证绕过：**
```bash

Access monitoring/protected features directly without completing verification

无需完成验证直接访问监控/受保护功能

curl -s https://monitor.target.com/dashboard
-H "Cookie: session=<your_session>" \

Try skipping directly to the post-verification endpoint

curl -s https://monitor.target.com/dashboard
-H "Cookie: session=<your_session>" \

尝试直接跳转到验证后的端点

Replay verification token on different account

在不同账户上重放验证令牌

curl -X POST https://target.com/verify
-d 'token=VALID_TOKEN_FROM_ACCOUNT_A&email=account_b@example.com'

**Grep patterns for client-side logic issues:**
```bash
curl -X POST https://target.com/verify
-d 'token=VALID_TOKEN_FROM_ACCOUNT_A&email=account_b@example.com'

**客户端逻辑问题的Grep模式：**
```bash

Find price calculations in JS

在JS中查找价格计算逻辑

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

Find internal URLs in JS bundles

在JS包中查找内部URL

grep -oE '"/(employee|internal|staff|admin|summit)[^"]*"' *.js
grep -oE '"/(employee|internal|staff|admin|summit)[^"]*"' *.js

Find unvalidated IP header usage in server code

在服务器代码中查找未验证的IP请求头使用情况

grep -iE "x-forwarded-for|x-real-ip|cf-connecting-ip" src/ -r

---
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.
  1. 服务器信任客户端提供的财务决策数据。开发人员将价格计算转移到前端，或通过表单/URL传递金额字段，但未在服务器端对照权威来源（产品数据库）重新验证。
  2. 仅在UI而非API中执行验证。前端通过验证网关隐藏功能，但后端API端点无需验证状态即可完全生效——任何认证请求都会成功。
  3. 基于IP的速率限制依赖可伪造的请求头。开发人员使用
    request.headers['X-Forwarded-For']
    而非实际连接IP实现速率限制，允许通过请求头操纵轻松绕过。
  4. 支付Webhook缺乏签名验证。开发人员实现“成功”Webhook时未验证支付服务商提供的HMAC签名，导致任何人都能POST虚假的成功通知。
  5. 内部/员工页面未设置访问控制。内部工具部署到生产域名但未添加认证中间件，原因可能是开发人员依赖隐蔽性（未公开URL）或忘记为新路由添加认证。
  6. 电话/回调验证仅为建议性而非强制性。系统接受电话号码并信任提交者，但未确认提交者拥有或控制该号码。
  7. 草稿/特定渠道店铺继承完整订单功能。Shopify等平台允许为特定渠道（员工活动）创建店铺，这些店铺未公开但只要知道URL，仍可完全正常下单。

Bypass Techniques

绕过技巧

DefenseBypass
IP-based rate limitingRotate 
X-Forwarded-For
, 
X-Real-IP
, 
True-Client-IP
, 
CF-Connecting-IP
headers per request
CAPTCHA on subscription formsUse header-based bypass first; if CAPTCHA is only on the web form, call the underlying API endpoint directly
Email verification gateAccess the post-verification API endpoint directly; replay valid tokens; check if 
verified=true
is a client-set cookie/param
Payment amount server validationModify currency to a lower-value currency; test with $0.00 or negative amounts; manipulate order IDs to reference different products
Webhook HMAC validationTest with no signature header; test with empty signature; test replay of a previously captured valid webhook with modified payload
Auth on internal pagesTry 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
防御措施绕过方法
基于IP的速率限制每次请求轮换
X-Forwarded-For
、
X-Real-IP
、
True-Client-IP
、
CF-Connecting-IP
请求头
订阅表单的CAPTCHA先尝试基于请求头的绕过；如果仅Web表单有CAPTCHA，直接调用底层API端点
邮箱验证网关直接访问验证后的API端点；重放有效令牌；检查
verified=true
是否为客户端设置的Cookie/参数
服务器端支付金额验证修改为低价值货币；测试$0.00或负金额；操纵订单ID引用不同产品
Webhook HMAC验证测试不携带签名请求头；测试空签名；测试重放捕获的有效Webhook并修改payload
内部页面认证尝试未认证访问；尝试低权限账户；尝试路径遍历变体（
/employee/../employee/
）
电话验证（发送OTP）提交他人号码且不验证OTP；检查系统是在提交时还是OTP确认后给予信任

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.
提交任何报告前，需回答以下三个问题：
  1. 攻击者当前能做什么？ 需具体：“未认证用户可免费下单获取实物商品”或“攻击者可绕过邮箱验证，无需拥有即可监控任意邮箱地址”或“攻击者可向任意地址发送无限订阅邮件”。模糊的影响会被拒绝。
  2. 受害者会损失什么？ 明确具体可归因的损失：财务损失（免费商品、欺诈性支付）、隐私损失（电话号码被伪造、未授权监控）、服务滥用（通过速率限制绕过发送垃圾信息）或安全降级（敏感操作信任未验证身份）。如果损失仅为理论性，需重新评估严重程度。
  3. 能否在10分钟内从零开始复现？ 创建新账户（或无需账户），按照记录的步骤操作，实现预期影响。如果无法在10分钟内可靠地完整复现，说明方法论不完整——提交前需完善。

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.
场景1——通过暴露的内部店铺免费获取实物商品（Shopify类） 某员工峰会页面作为向员工分发免费书籍的私有渠道，部署到公开的Shopify店铺。该URL可通过JS包分析或链接分享发现。匿名用户访问该URL后，无需认证即可浏览并完成结算，由公司承担运费获取实物商品。影响：每笔订单都会造成直接财务损失，若未及时发现可能被批量下单。
场景2——通过中途篡改操纵支付（Valve/Steam类） 支付流程在重定向到第三方支付服务商（Smart2Pay）前，通过客户端控制的参数传递订单金额和货币。攻击者使用Burp Suite拦截重定向并修改金额字段，仅需支付$0.01，而应用的Webhook（未验证HMAC）会接受服务商的确认，并将完整商品/服务额度计入账户。影响：严重财务损失；攻击者以近乎零成本获取全额价值的商品/服务，且可无限重复操作。
场景3——绕过邮箱验证实现未授权监控（Mozilla类） 某数据泄露监控服务要求邮箱验证后才能启用地址监控警报。验证检查仅在UI流程中执行，但底层API接受使用有效会话为任意地址设置监控的请求——完全跳过验证步骤。攻击者可为非本人所有的邮箱设置监控，接收受害者账户的泄露通知数据（可能包括凭证泄露状态）。影响：隐私侵犯；攻击者可在受害者不知情或未同意的情况下，获取目标邮箱是否存在数据泄露的情报。

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

已公开报告引用（补充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).
  1. 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)
  2. 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
  3. 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)
  4. 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
  5. Stripe — Pay using archived price via mid-flow swap (H1 #1328278)
    • Subclass: cart-state TOCTOU / cancel-then-deliver (price-version race at checkout)
    • Payload: merchant archives an old price (e.g., $5 instead of new $50). Buyer starts checkout via the new payment-link, then mid-flow swaps 
      price_id
      back to the archived one. Stripe charges $5; subscription provisions at the new tier
    • Root cause: payment-link validates "is active", price object validates "exists" — but the join "price.active AND price ∈ link.allowed_prices" is missing
    • Year: 2021 — Stripe Medium (per-subscription recurring loss)
以下真实、已验证的漏洞赏金/协调披露案例扩展了本技巧。所有案例均具有可衡量的财务影响（已证实实际损失或可量化的平台范围暴露）。
  1. Stripe——费用折扣竞态重复兑换 (H1 #1849626)
    • 子类：优惠券/折扣竞态重复兑换 + 金融原语
    • Payload：Stripe Support发放了一次性$20,000的费用抵扣。研究人员捕获“接受折扣”的POST请求，通过Burp Turbo Intruder并行重放30次，每次接受都会重新为账户抵扣费用
    • 根本原因：折扣接受端点缺少幂等性；(account_id, discount_id)无唯一约束
    • 年份：2023 — 赏金$5,000，修复前累计产生$600,000的免手续费交易（按3%费率计算，Stripe实际损失约$18,000）
  2. Reverb.com——礼品卡竞态重复兑换 (H1 #759247)
    • 子类：礼品卡/储值卡竞态重复兑换
    • Payload：使用单张有效礼品卡，通过Turbo Intruder从10个套接字并行POST到
      /redeem
      。账户余额会被充值N倍面值金额
    • 根本原因：礼品卡表无行级锁；余额扣除和充值在不同事务中执行
    • 年份：2019 — 赏金$1,500
  3. Upserve / OLO——负数量价格篡改 (H1 #364843)
    • 子类：购物车负数量价格篡改
    • Payload：
      POST /api/order {"items":[{"id":1,"qty":1,"price":50},{"id":2,"qty":-3,"price":50}]}
      — 订单总额计算为
      -$100
      ，支付捕获时向下取整为约$0，商品仍会配送
    • 根本原因：服务器计算
      qty * price
      但未添加
      qty >= 1
      的校验
    • 年份：2018 — 该子类的经典案例（仅确认的项目）
  4. Krisp——通过PUT篡改实现低价购买席位 (H1 #1446090)
    • 子类：单位价格批量赋值 / 数量折扣操纵
    • Payload：
      PUT /v2/seats
      请求体包含服务器信任的
      price
      字段。将
      price=1
      替换为原价$60。订阅更新后，计费引擎按$1/席位收取100个席位的费用
    • 根本原因：服务器从请求体读取价格而非通过plan_id查询；典型的批量赋值漏洞
    • 年份：2021 — Stripe计费的SaaS定价暴露
  5. Stripe——通过中途切换使用归档价格支付 (H1 #1328278)
    • 子类：购物车状态TOCTOU / 取消后交付（结算时价格版本竞态）
    • Payload：商家归档旧价格（如$5，新价格为$50）。买家通过新支付链接开始结算，中途将
      price_id
      切换回归档价格。Stripe收取$5；订阅按新层级生效
    • 根本原因：支付链接验证“是否激活”，价格对象验证“是否存在”——但缺少“price.active AND price ∈ link.allowed_prices”的联合校验
    • 年份：2021 — Stripe中等严重程度（每个订阅的持续损失）

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".
  • hunt-race-condition
    ——逻辑流程中的每个唯一性/配额检查都是竞态条件的候选对象。攻击链原语：业务逻辑（优惠券/抵扣/促销）+ 竞态条件 → 通过Turbo Intruder在单个TCP数据包中重复兑换优惠券N次。
  • hunt-idor
    ——信任客户端提供标识符（order_id、tenant_id、beneficiary_id）的逻辑流程与IDOR直接重叠。攻击链原语：业务逻辑步骤跳过 + beneficiary_id的IDOR → 从受害者账户转移资金。
  • hunt-api-misconfig
    ——步骤跳过和验证绕过通常与批量赋值字段共存。攻击链原语：业务逻辑邮箱验证跳过 + API批量赋值（
    verified:true, role:admin
    ）→ 无需控制邮箱即可接管账户（ATO）。
  • hunt-ato
    ——密码重置、邮箱更改和恢复流程中的逻辑漏洞是核心ATO路径。攻击链原语：业务逻辑（邮箱更改无需重新认证）+ 
    hunt-ato
    路径2 → 静默替换受害者邮箱 → 将密码重置到攻击者邮箱。
  • security-arsenal
    ——加载业务逻辑探针清单（负数量、小数溢出、货币切换、通过直接URL导航跳过步骤、状态机逆向）和拒绝清单，避免提交无效漏洞。
  • triage-validation
    ——应用7问题验证（尤其是问题4“外部攻击者无需不现实的前置条件即可利用吗？”）：逻辑漏洞需要具体的资金/PII/状态影响，而非仅仅“流程看起来奇怪”。