官网：http://securitytech.cc/
Top Bugs That Actually Paid Bounties in 2025
好——说正经的。在我上一篇文章里我讲了 P4 漏洞那种稳定可靠的收入——很多猎人靠它吃饭。但说实话，虽然稳定能付账，真正让人肾上腺素飙升的，是那种高额钜奖。
你懂的那种漏洞。会让你靠近屏幕、把多个链条小心拼接起来，最后报告结尾出现四位数（或接近）奖金打到账户里的那种。
接近四位数
在 2025 年，漏洞赏金的竞争比以往更激烈，但高影响力漏洞依然存在——只是需要更敏锐的眼光和更深入理解现代应用是如何构建与被攻破的。
下面是今年给我带来高额回报的漏洞类别，并附上促成发现它们的高层次 POC 思路。
1. 经典回归：GraphQL 中的 SQL 注入
大家以为 SQLi 已经是历史遗留问题，但它迁移到 GraphQL 端点后又重获新生。复杂的查询和各个 GraphQL 实现之间缺乏统一的输入消毒，打开了新的攻击面。
为什么能拿高赏金：
直接访问数据库几乎总是属于高危问题。GraphQL 查询中的单一注入点就能泄露大量敏感用户数据、交易记录或公司内部信息。此类漏洞的赏金通常从 $2,500 起，往往能达到 $10,000+。
“恍然大悟” 的 POC：
我在测试一个用 GraphQL 做数据抓取的金融科技应用。常用字段受保护，但我注意到一个少用的 searchTransactions 查询，接受一个 filter 参数。
步骤 1：先简单探探错误。
query {
searchTransactions(filter: "test'") {
id
amount
}
}
```
- 观察：抛出了冗长的 SQL 错误，泄露了后端数据库（PostgreSQL）。
步骤 2：为了避免破坏性，升级为基于布尔的盲注。
```graphql
query {
searchTransactions(filter: "x' OR 1=1--") {
id
amount
}
}
```
- 观察：本该返回空的结果反而返回了所有交易。确认存在注入！
步骤 3：报告中包含 POC、具体的可注入查询，以及潜在影响（可完整导出所有用户交易）。关键是证明我能操纵查询以提取未授权数据。
---
## 2. 现代祸害：通过 API 端点的非授权直接对象引用（IDOR）
IDOR 并不新鲜，但在 2025 年它藏在你的 REST 与 GraphQL API 里更常见。随着移动 App 与单页应用（SPA）的兴起，开发者常常忘记在后端重新实现授权检查，错误地以为前端会处理。
**为什么能拿高赏金：**
这种问题惊人地常见，而且可以导致大规模数据泄露。我发现过的 IDOR 能访问任意用户的私有文档、私信，甚至管理员面板。赏金通常在 $1,000 — $5,000，视暴露数据而定。
> **“恍然大悟” 的 POC：**
> > 我在查看某项目管理应用的网络流量。创建了一个私有项目后，我看到一个请求：
> > `GET /api/v1/projects/14377/documents`
步骤 1：经典测试。把请求里的项目 ID 从 `14377` 改成 `14378`。
> `GET /api/v1/projects/14378/documents`
- 观察：我成功访问了并非我的项目的文档列表。
步骤 2：我不止于此，查找是否有 `POST` 接口能在别人的项目中创建文档。
> `POST /api/v1/projects/14378/documents`
> > Body: `{"title":"Hacked","content":"You have an IDOR."}`
- 观察：服务器接受了！我现在既能读也能写非授权项目。
步骤 3：报告演示了完整攻击链：未授权读取与未授权写入，证明项目隔离被完全突破。
（查看大图）
IDOR 获赏示意
---
## 3. 无声杀手：Webhook 与文件处理中的服务器端请求伪造（SSRF）
现代应用常需从外部抓取数据：处理来自 URL 的图片、验证 webhook，或拉取用户提交的链接。这类对外请求的信任就是攻击者的黄金门票。
**为什么能拿高赏金：**
成功的 SSRF 可能造成灾难性后果：可用来扫描内网、访问云元数据服务（窃取云凭证！）、或攻击本不应暴露的内部系统。若能接触到 AWS IAM 角色或其他内部资产，赏金通常 $3,000+。
**“恍然大悟” 的 POC：**
某社交平台允许通过提供 URL 设置头像。
步骤 1：我搭了一个公开端点，查看服务器是否会连回来。
> URL: `http://my-burp-collaborator.net/test`
- 观察：我收到了来自应用服务端 IP 的 HTTP 请求。确认服务器在抓取该 URL。
步骤 2：尝试让它调用内部地址。
> URL: `http://redacted/latest/meta-data/`（AWS 元数据地址）
- 观察：请求挂起了，感觉可疑。我又试了本地环回地址：`http://127.0.0.1:8080/admin`
步骤 3：应用返回了一个错误信息，泄露了来自内部 `/admin` 端点的部分响应！这确认了能与内部服务交互。我的报告包含了 Collaborator 的交互记录和来自内部 admin 面板的（部分）响应。
（查看大图）
SSRF 导致内网服务访问示意
---
## 4. 逻辑炸弹：多步骤流程中的业务逻辑漏洞
这类漏洞表示你从仅仅依赖扫描器，迈向用脑子找问题。这些错误不是技术实现层面的简单缺陷，而是破坏应用预期工作流程的设计问题。
**为什么能拿高赏金：**
自动化工具几乎找不到这类问题，且每个应用都独一无二。影响范围可以从无限试用到以极低价格买到商品。我就因为一次电商结账流程的机智绕过拿到了 $4,200。
**“恍然大悟” 的 POC：**
某电商提供 5 美元的“礼物包装”服务。流程是：
1. 加入购物车（$100）
2. 2. 进入结账
3. 3. _客户端_ 计算税与礼物包装（$100 + 税 + $5）
4. 4. _服务端_ 确认最终金额并使用 Stripe 创建支付 intent
POC：
步骤 1：我用 Burp 截获最后的 `POST /checkout` 请求。
步骤 2：我发现一个参数：`"total_amount": 115.00`，我把它改成 `"total_amount": 0.50`。
步骤 3：我转发请求。
- 观察：服务器信任了这个值，并创建了一个 0.50 美元的 Stripe 支付 intent。我支付后，订单被标记为已支付，$100 的商品以 $0.50 发货。
漏洞在于服务器没有重新计算总价，而是信任客户端传来的值。报告中就是一步步演示了这次篡改。
（查看大图）
业务逻辑漏洞示意
---
## 结语：动脑，而不是盲扫
这些高额漏洞的共同点？都需要人工测试与批判性思考。
- 绘制应用地图：理解数据流向。用户输入去了哪里？授权如何校验？
- - 问“为什么？”：为什么会有这个参数？为什么服务器需要抓取这个 URL？这个工作流背后的业务逻辑是什么？
- - 串联漏洞：一个低危的开放重定向可能在偷 OAuth token 时变成高危；一个小的 IDOR 可能配合 XSS 针对管理员实施更严重攻击。
在 2025 年，拿到高额赏金的猎人不是跑最多工具的人，而是比开发者更懂得这个应用的人。
保持好奇，动脑思考，狩猎愉快！
想更深入进阶技巧？我下一篇文章会拆解我是如何用 Burp Suite 的 Macro 与 Extension 自动化复杂认证流程来做测试的。
# 公众号：安全狗的自我修养
# vx：2207344074
# Gitee：gitee.com/haidragon
# GitHub：github.com/haidragon
# Bilibili：haidragonx
扫一扫
338
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
