无需用户名密码：HTTP 头绕过认证拿 3000 美元赏金

导语：Recon 阶段发现一个跳转到第三方认证的子域，从 JS 文件里挖出 50 多个 API 端点，发现后端只检查 Authorization 头是否存在——加一个空 Authorization 头就能绕过全部认证，最终拿到 3000 美元 Critical 漏洞赏金。

引言

在做目标侦察的时候，我撞上一个有意思的认证绕过漏洞，最终报了一个 Critical（严重）级别报告，拿到了 3000 美元赏金。

这个漏洞是结合 JavaScript 分析、API 端点枚举、对应用底层认证机制的理解挖出来的。

本文把这个发现过程和根本原因完整复盘一遍。

测试与思考

这次发现是在一次常规侦察中开始的。

枚举子域时，我撞上一个立刻把用户重定向到另一个站点去做认证的子域。第一眼看上去是个标准的登录流程，所以在它完成重定向之前，我顺手打开页面源码，看看有没有什么有趣的东西暴露出来。

源码里看到一个应用加载的 JavaScript 文件。JS 文件经常藏着有用信息，于是我把它下下来开始审。

第一个目标是提取应用调用的所有 API 端点。

快速过了一遍代码，找到了几个 API 端点，立刻打开 Burp Suite 开始测。

可惜每个请求都返回同一个响应：

401 Unauthorized

到这一步，端点看起来都被正确保护着。

但是盯着响应的时候，脑子里冒出一个问题：

应用到底怎么知道用户已经认证了？

我没继续瞎测端点，而是回到那个 JS 文件，开始顺着应用的认证逻辑往下追。

翻完代码，找到下面这段：

a1&&n1.set(
    "Authorization",
    "Basic " +
    btoa(
        (a1.username || "") +
        ":" +
        (a1.password
            ? unescape(encodeURIComponent(a1.password))
            : "")
    )
)

这玩意儿一下子抓住了我的注意力。

应用用的是 HTTP Basic 认证（HTTP 基本身份验证），期望请求里带一个由用户名和密码构造的 Authorization 头。

我第一反应是去找有效凭据。

翻 GitHub
翻 URLScan

搜了配置文件、泄露的凭据、历史数据，能暴露应用用户名或密码的边边角角都翻了一遍。

折腾了好一阵子，啥都没找到。

到这一步，另一个念头冒出来了……

如果我不去找有效凭据，而是去想：后端是不是只检查 Authorization 头是否存在？

为了验证这个猜想，我重新发了同一条请求，但加了一个这样的头：

Authorization: Basic

请求发出去，响应回来了：

最有趣的是，这个洞不限于单个端点。发现只要加 Authorization: Basic 头就能绕过认证后，我又在从 JS 文件里挖出来的近 50 个 API 端点上挨个测了一遍。绕过行为稳定复现，能访问的功能覆盖客户数据的查看、创建、修改、删除，以及各种内部系统设置。无需任何有效的用户名或密码——只要 Authorization 头存在就行。

最终拿到一个 Critical 报告，奖金 3000 美元。

根本原因

问题出在 HTTP Basic 认证的校验不严。后端只检查了 Authorization 头是否存在，但没有正确校验提供的凭据。结果是，带 Authorization: Basic 但没有有效用户名或密码的请求被错误地当作已认证请求放行。

红队技术点评

这个洞是典型的”认证状态机被绕过”，几个点值得拆开看：

JS 文件就是 API 字典。前端项目几乎一定会把全部 API 端点写进 JS bundle 里，而 JS 文件 90% 是公开可拉取的。拿到 JS 后用 grep 抓 /api/、fetch(、axios. 这类关键词，5 分钟就能拉出几十个端点，比目录扫描还全。

“状态检查”是“身份验证”而不是“凭据检查”。作者那句”后端是不是只检查 Authorization 头是否存在”是点睛之笔。HTTP Basic 认证在 RFC 7617 里规定必须 base64 解码出 user:pass 然后验证，但实际开发里经常只判断字符串前缀是不是 Basic ，后面跟什么都不管。这种”形似神不似”的认证在自研网关、中间件里很常见。

绕过路径不限于一个端点。一旦认证这层被穿透，整个应用的所有受保护接口都等于裸奔。这就是认证漏洞经常被评为 Critical 的原因——一个洞，一锅端。