hunt-business-logic

高价值目标

在金融交易、身份验证和访问控制与现实后果交汇的平台中，业务逻辑漏洞的收益最高。最有价值的目标包括：

• 电商与支付平台（Valve/Steam、Shopify）——操纵支付流程、免费获取商品、篡改价格
• 市场平台与零工经济应用（Airbnb、Uber）——绕过身份验证，进而实施欺诈或引发不安全互动
• 采用分级访问权限的 SaaS（Mozilla Monitor）——绕过验证，在无权限的情况下解锁监控功能
• 高流量消费类应用（Snapchat、Yelp）——绕过速率限制，从而大规模发送垃圾信息、枚举数据或实施滥用

高收益资产类型：结账流程、订阅端点、回调/验证系统、Webhook 处理程序、暴露在互联网上的员工/内部门户，以及任何信任客户端提供的数据来做出授权决策的端点。

---

攻击面信号

需要关注的 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) { ... }）
• fetch('/api/subscribe', { method: 'POST', body: ... })，且没有防 CSRF 令牌或速率限制令牌

技术栈信号：

• 带有草稿/未发布渠道页面的 Shopify 店面
• 使用基于 IP 的速率限制、但未绑定会话/账户的应用
• 未验证 HMAC 签名的支付 Webhook
• 启用功能前未验证所有权的短信/电话回调流程

逐步狩猎方法

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，或将货币改为价值较低的货币。查找接受支付确认的 POST 回调／webhook 端点，并测试它们是否会验证 HMAC／签名。

5. 测试电话／回拨号码验证。 每当平台接受回拨号码时，测试：能否将其设为不属于你的号码？平台是否会拨打／发送短信到该号码，并仅凭提交号码就授予信任？尝试将其设为受害者的号码。

6. 检查未受保护的员工／内部界面。 在 Shodan、GitHub、JS 包和 Wayback Machine 中搜索内部子域名／路径引用。测试未经身份验证是否可以访问。检查这些界面是否允许下单、访问数据或提升权限。

7. 验证业务影响。 针对每项发现，确定这是否会造成财务损失、未授权访问或数据泄露。记录完整的攻击链。

---

载荷与检测模式

通过轮换标头绕过速率限制：

# 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

支付篡改 — 修改传输中的价格：

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"}'

发现未经身份验证的内部页面：

# 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

绕过电子邮件验证：

# 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":"[email protected]"}'

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

用于查找客户端逻辑问题的 Grep 模式：

# 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

---

常见根本原因

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，仍可正常下单。

---

绕过技术

防御措施	绕过方法
基于 IP 的速率限制	每次请求轮换 X-Forwarded-For、X-Real-IP、True-Client-IP、CF-Connecting-IP 标头
订阅表单上的 CAPTCHA	优先尝试基于标头的绕过；如果 CAPTCHA 只出现在网页表单上，直接调用底层 API 端点
邮箱验证关卡	直接访问验证后的 API 端点；重放有效令牌；检查 verified=true 是否是由客户端设置的 Cookie/参数
服务端验证付款金额	将货币改为价值较低的货币；尝试 $0.00 或负数金额；篡改订单 ID 以引用其他商品
Webhook HMAC 验证	尝试不带签名标头或使用空签名标头（验证是否实际生效——只有在未强制验证时，篡改后的载荷才会“通过”）；重放捕获到的未修改 Webhook，以测试是否缺少幂等性/防重放机制
内部页面上的身份验证	尝试未登录访问；尝试使用低权限账户；尝试路径遍历变体（/employee/../employee/）
电话验证（发送 OTP）	不经过 OTP 验证就提交他人的号码；检查系统是在提交号码时还是在确认 OTP 后授予信任

---

Gate 0 验证

撰写任何报告前，请回答以下三个问题：

1. 攻击者现在能做什么？ 请具体说明：“未登录用户可以零成本下单购买实物”或“攻击者可以绕过邮箱验证，在未拥有某个邮箱地址的情况下监控该邮箱”或“攻击者可以向任意地址发送无限量的订阅邮件。”影响描述含糊 = 驳回。

2. 受害者会遭受什么损失？ 明确具体且可归因的损失：经济损失（免费获得商品、欺诈性付款）、隐私损失（伪造电话号码、未经授权的监控）、服务滥用（通过绕过速率限制发起垃圾邮件活动），或安全性降低（未经验证的身份被信任，可执行敏感操作）。如果损失纯属理论推测，请重新评估严重性。

3. 能否在 10 分钟内从头复现？ 创建一个新账户（或不使用账户）。按照你记录的步骤操作，并实现相应影响。如果你无法依据所写步骤，在 10 分钟内从头到尾稳定地复现问题，则说明方法尚不完整——提交前请完善。

---

实际影响示例

场景 1 — 通过暴露的内部店铺免费获取实物商品（类似 Shopify） 某员工峰会页面被部署到公开的 Shopify 店铺，作为向员工免费发放书籍的专用渠道。通过分析 JS bundle 或分享链接即可发现该 URL。匿名用户访问该 URL 后，无需身份验证即可浏览商品并完成结账，实物商品由公司承担运费并寄出。影响：每笔订单都会造成直接经济损失；若未能及时发现，还可能被批量下单。

场景 2 — 通过篡改传输中的数据操纵支付（类似 Valve/Steam） 支付流程通过由客户端控制的参数传递订单金额和货币，然后重定向到第三方支付服务提供商（Smart2Pay）。攻击者可以使用 Burp Suite 拦截重定向并修改金额字段，以 $0.01 完成真实支付；由于应用的 webhook 未进行 HMAC 验证，因此会接受服务提供商的确认，并向账户发放完整的商品／服务。影响：造成严重的经济损失；攻击者几乎无需付费即可获得全部价值的商品／服务，而且可以无限次重复利用。

场景 3 — 绕过电子邮件验证，未经授权地进行监控（类似 Mozilla） 某泄露监控服务要求先验证电子邮件地址，才能为其启用监控提醒。验证检查仅在 UI 流程中执行，但底层 API 使用有效会话即可接受针对任意地址的监控设置请求，完全跳过验证步骤。攻击者可以监控自己并不拥有的电子邮件地址，并接收受害者账户的泄露通知数据（可能包括凭据是否已泄露）。影响：侵犯隐私；攻击者可以在目标不知情或未同意的情况下，获知目标的电子邮件是否出现在数据泄露事件中。

---

已披露报告引用（补充 +5 — 2016-2023）

以下五个真实且经过验证的漏洞赏金 / 协调披露案例扩展了此技能。五个案例都涉及可衡量的财务影响（已证实的实际损失或可量化的平台级风险敞口）。

8. Stripe — 费用折扣竞态重复兑换 (H1 #1849626)

   • 子类：优惠券 / 折扣竞态重复兑换 + 财务原语
   • 载荷：Stripe 支持团队应用了一笔一次性 $20,000 费用抵扣额度。研究人员捕获了“接受折扣” POST 请求，并通过 Burp Turbo Intruder 并行重放 30 次，每次接受都会再次为账户记入抵扣额度
   • 根本原因：折扣接受端点缺少幂等性；(account_id, discount_id) 上没有唯一约束
   • 年份：2023 — $5,000，修复前累计产生了 $600,000 的免手续费交易（按 3% 抽成计算，Stripe 实际损失约为 $18,000）

9. Reverb.com — 礼品卡竞态重复兑换 (H1 #759247)

   • 子类：礼品卡 / 商店额度竞态重复兑换
   • 载荷：使用一张有效礼品卡，通过 Turbo Intruder 从 10 个套接字并行向 /redeem 发送 POST 请求。余额会增加面值的 N 倍
   • 根本原因：gift_card 表没有行级锁；余额扣除和入账分别发生在不同事务中
   • 年份：2019 — $1,500

10. Upserve / OLO — 负数量价格篡改 (H1 #364843)

    • 子类：购物车中负数量导致价格篡改
    • 载荷：POST /api/order {"items":[{"id":1,"qty":1,"price":50},{"id":2,"qty":-3,"price":50}]} — 订单总额计算结果为 -$100，在支付扣款时被压到约 $0，但食品仍会送出
    • 根本原因：服务器计算 qty * price，却没有 qty >= 1 检查
    • 年份：2018 — 该子类的经典引用（仅获确认的项目）

11. Krisp — 通过 PUT 篡改实现按席位少付费 (H1 #1446090)

    • 子类：单价批量赋值 / 数量折扣操纵
    • 载荷：PUT /v2/seats 请求体中包含服务器信任的 price 字段。将 price=1 而非 $60。订阅更新后，计费引擎按每个席位 $1 收取 100 个席位的费用
    • 根本原因：服务器从请求体读取价格，而不是根据 plan_id 查询价格；这是典型的批量赋值漏洞
    • 年份：2021 — Stripe 计费的 SaaS 定价风险敞口

12. Stripe — 通过流程中途切换使用已归档价格 (H1 #1328278)

    • 子类：购物车状态 TOCTOU / 取消后仍交付（结账时的价格版本竞态）
    • 载荷：商家归档旧价格（例如 $5，而新价格为 $50）。买家通过新支付链接开始结账，然后在流程中途将 price_id 切回已归档的价格。Stripe 按 $5 收费；订阅则按新层级开通
    • 根本原因：支付链接会验证“是否处于启用状态”，价格对象会验证“是否存在”——但缺少“price.active AND price ∈ link.allowed_prices”这一关联校验
    • 年份：2021 — Stripe 中危（每个订阅造成持续损失）

相关技能与攻击链

• 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 问门槛（尤其是 Q4：“外部攻击者能否在没有不切实际的前提下利用此问题？”）：逻辑漏洞需要造成具体的金钱／PII／状态影响，不能只说“流程看起来很奇怪”。