如何在 30 分钟内发现认证绕过如何在30分钟内发现认证绕过你刚接到一个新的API测试目标范围很大几十也许上百个端点你一

官网：http://securitytech.cc/

如何在 30 分钟内发现认证绕过

你刚接到一个新的 API 测试目标。范围很大——几十、也许上百个端点。你一小时后有个会议，想尽快找到有影响力的问题。

我很懂那种感觉。要交出成绩、面对一长串路径、又想把扫描器对着它一阵猛轰然后寄希望于好运。要是你能在咖啡凉之前找到一个关键的认证绕过呢？

这不是魔术，而是方法论。别试图把海水都煮干。我们跑一个聚焦的 30 分钟剧本，找出最常见且最关键的 API 认证缺陷。

为什么大多数 API 认证测试会失败

听着，API 认证不是登录时通过那一扇门而已。它应该像门卫一样，在建筑物里每个房间的门口都查验你的证件。问题是，有些门卫在岗时睡着了。

大多数测试者开始时会犯两种大错：

“喷子战术（Spray and Pray）”： 启动工具、载入通用字典、对 API 猛轰，期待出现红旗。噪音很大，而且老实说会漏掉那些基于逻辑的微妙缺陷。
1. “完美主义瘫痪（Perfectionist Paralysis）”： 花好几个小时画全量 API 地图、理解每个参数、记录每个函数，才发出第一条恶意请求。等他们开始时，测试时间已经过了一半。

思维要换：我们不是在 30 分钟内找出所有漏洞。我们是在寻找那些黄金般的“低垂果实”。找的是开发者在匆忙上线 feature 时反复犯的模式。

按下回车以查看大图（或点击）

前 15 分钟：高影响力分流（High-Impact Triage）

这是冲刺。设定计时器，我们开始。

第 1–5 分钟：未认证直测（Unauthenticated Gut Check）

听起来几乎太简单以致不靠谱，但你会惊讶。把你握有的每一个端点——从用户资料页到重置密码接口——都把 Authorization 头删掉。直接撕掉它。

操作示例：

原请求：

curl -X GET 'https://api.example.com/v1/users/me/profile' \
-H 'Authorization: Bearer eyJhbGciOiJIUzI...'

改成：

curl -X GET 'https://api.example.com/v1/users/me/profile'

为什么有效： 开发者常常忘了把认证中间件应用到新旧或非生产的端点上，结果这些端点意外被发布。我见过 /debug、/status、以及 /v1/internal/... 这类端点直接打开，泄露敏感系统信息或用户数据。如果你收到 200 OK 而不是 401 Unauthorized 或 403 Forbidden，说明你很可能找到第一个漏洞。

第 6–10 分钟：JWT 基础 — 明显的错误

若应用使用 JSON Web Tokens (JWT)，那它们就是下一个目标。先别纠结复杂的密码学攻击。我们寻找简单易触达的问题。

操作： 拿到你的 Bearer token，贴到 jwt.io 之类的网站。先看解码后的 payload。有没有敏感信息？我曾经发现一个 JWT 的 payload 里居然包含用户的密码哈希和另一个 API 的 key——漏洞就是这么明显。

快捷测试：

alg:none 技巧。 找到 JWT（由三部分以点分隔），解码头部（header），把 "alg" 改为 "none"，再重新编码。然后把 token 的第三部分（签名）整段删除。发送请求。有时服务器会直接接受。
- 弱秘钥。 若 alg 是 HS256，签名是用一个 secret。试几个常见且糟糕的 secret，比如 secret、123456、password 或公司名。

示例 payload：

{
"user_id": 123,
"user_role": "member",
"can_delete_account": false,
"exp": 1729178400
}

第 11–15 分钟：BOLA/IDOR 快速扫（水平越权）

这是重头戏。Broken Object Level Authorization（BOLA），也称为 IDOR，是最常见且最关键的 API 漏洞之一。它允许你查看或操作不属于你的数据。

操作： 找任何 URL 或请求体里带 ID 的端点，例如 /api/v2/users/123/profile 或 /api/invoices/987。

方法：

注册两个账户：用户 A 和用户 B。
- 使用用户 A 登录，访问你的资料，假设请求为 /api/v2/users/123/profile。
- 使用用户 B 登录，访问其资料，假设是 /api/v2/users/456/profile。
- 回到用户 A，重放最初的请求，把 ID 从 123 改为 456。

如果以用户 A 的身份你得到了用户 B 的资料，你就找到了一个严重的认证绕过。服务器确认了你是有效用户，但没验证你是不是正确的用户。

按下回车以查看大图（或点击）

接下来的 15 分钟：提升权限（Escalating Your Privileges）

你已经检查了缺失认证和水平移动。现在看看是否能垂直提升——变成管理员。

第 16–20 分钟：参数篡改（Parameter Tampering）

开发者喜欢把权限信息放在 JSON body 或 JWT 里。他们信任客户端不去改它。我们就改给他们看看。

操作： 查找任何暗示权限的参数，可能在 POST 的 JSON 对象里，或在上面解码的 JWT payload。

方法：

看到 "isAdmin": false？改成 true。
- 看到 "role":"user"？改成 "admin"。
- 看到 "account_type":"basic"？改成 "premium"。

我在一次渗透测试中，把 "is_premium": false 改成 true，结果解锁了企业级功能，包括访问组织中其他用户的数据。就是一次布尔值翻转导致的关键漏洞。

第 21–25 分钟：HTTP 方法篡改（Method Tampering）

经典手法。开发者对 GET 施加了严格的认证检查，但忘了对相同端点的其它方法应用相同检查。

操作： 找一个可以查看对象的端点，比如 GET /api/v1/posts/latest。

方法： 在 Burp Repeater 中，把请求顶部的 HTTP 动词改掉：

尝试 POST 看是否能在未认证下创建一条帖子。
- 尝试 PUT 看是否能在未认证下覆盖现有内容。
- 尝试 DELETE 看是否能删掉它。

你押注的是懒惰编码，而这种赌有时会赢。

第 26–30 分钟：端点猜测游戏（Endpoint Guessing）

最后五分钟用于有策略的猜测。你已经观察到 API 的结构，现在推断其它可能存在的路径。

操作： 如果你频繁看到 /api/v1/users/{id} 和 /api/v1/accounts/{id}，那很可能在 /api/v1/ 下还有其它端点。

方法： 不要盲目爆破，做聪明的猜测：

尝试常见的管理或调试路径：/api/v1/admin/、/api/v1/management/、/api/v1/status。
- 名词复数化：看到了 /user/123，试试 /users。
- 使用高质量的小型 API 字典（比如 GitHub 上 SecLists 的某些列表）快速检查常见的未链接端点。

30 分钟工具包

你不需要昂贵或复杂的配置。说实话，只要这些就够了：

Burp Suite： 免费版足够用。Repeater 是你的好朋友。30 分钟里你会一直用它调整请求。
- 文本编辑器： 用来粘贴 API 端点、JWT 和有趣的响应。
- Postman（可选）： 方便组织请求，想保存的话可以用，但冲刺阶段不是必须。
- Autorize（Burp 插件，可选）： 在完成这 30 分钟扫描后，像 Autorize 这样的工具可以自动化 BOLA/IDOR 检查。

从 30 分钟到完整渗透测试

就是这样。一个结构化、限时的方法，远比混乱随机的测试更有效。这个 30 分钟剧本不会找到所有漏洞，但会覆盖大量常见且高危的认证缺陷。它还能带来势头。

你的作业：选一个当前目标，设定 30 分钟计时器，照着这个剧本跑一遍。看看能发现什么。

一旦你找到这些初始漏洞，游戏就变了。下一步是串联它们——比如用 IDOR 偷到管理员的会话 token，然后用那个 token 访问隐藏的调试端点。

但那是另一篇文章的内容。

如何在 30 分钟内发现认证绕过

官网：http://securitytech.cc/