swagger api 未授权访问漏洞

Swagger UI 页面直接暴露在公网，未授问漏点开就能看到所有接口定义，权访连测试按钮都能用——这不是未授问漏什么新鲜事，但直到今天，权访仍有大量系统栽在这个坑里。未授问漏上个月我帮一个朋友看他公司的权访后台，顺手把域名后面加了个 /swagger-ui.html，未授问漏页面刷地就出来了。权访接口列表整整齐齐，未授问漏从用户登录到订单删除，权访全在那儿躺着。未授问漏他当场愣住，权访说这玩意儿不是未授问漏内部用的吗？

问题就出在“内部用”这三个字上。开发阶段为了方便调试，权访把 Swagger 集成进项目，未授问漏文档自动生成，接口随便测。上线时一忙，忘了关。或者觉得“反正没几个人知道路径”，就留着。攻击者根本不需要猜，目录扫描工具跑一遍，/swagger-ui.html、/v2/api-docs、/swagger-resources 这些路径全在字典里。扫到了，就等于拿到了系统的接口地图。

拿到地图之后呢？很多接口压根没做权限校验。Swagger 页面本身不校验，它只是展示。但那些被展示的接口，如果后端没有加认证逻辑，攻击者可以直接在 Swagger UI 上填参数、点 Execute。我见过一个案例，某电商后台的 /user/list 接口，Swagger 里点一下，返回了全站用户的手机号和地址。还有一个更离谱的，/admin/deleteUser?id=1 这种接口，Swagger 页面上直接就能调，连 token 都不用带。开发人员可能觉得“这个接口只有管理员会访问”，但 Swagger 把路径和参数全公开了，谁都能访问。

为什么这种漏洞反复出现？我观察下来，根子在于开发流程里的“临时”心态。Swagger 是开发期工具，上线前应该被排除在生产环境之外。但很多项目用的是同一套配置文件，改个 spring.profiles.active 就上线了，Swagger 的依赖和配置原封不动。有人会说“我加了权限拦截”，但拦截的是业务接口，Swagger 自己的页面路径往往被放行。还有人把 Swagger 藏在一个复杂路径下，比如 /api/internal/docs，觉得够隐蔽。可目录扫描工具连 robots.txt 都不放过，这种路径根本藏不住。

更麻烦的是，Swagger 泄露的不只是接口列表。/v2/api-docs 返回的 JSON 里，包含每个接口的请求方法、参数名、参数类型、甚至示例值。攻击者拿到这些，可以精准构造请求。比如某个接口参数叫 userId，类型是 integer，那就可以直接遍历。如果参数叫 filePath，那可能尝试路径穿越。Swagger 文档把攻击面从“黑盒”变成了“白盒”，省去了大量猜测时间。

怎么防？最直接的办法：生产环境彻底关掉 Swagger。Spring Boot 项目里，用 @Profile("!prod") 注解配置类，或者把 springfox.documentation.enabled 设为 false。如果非得留着，至少加一层 HTTP Basic 认证，或者限制来源 IP。但说实话，加认证也未必安全——如果认证凭证泄露，或者认证逻辑有绕过，Swagger 照样暴露。我倾向于一刀切：生产环境不该有 Swagger 页面。需要文档？用静态 Markdown 或者内部 Wiki 代替。

另外，别只盯着 Swagger UI 的 HTML 页面。/v2/api-docs 这个 JSON 端点才是核心，很多扫描器直接请求它。还有 /swagger-resources 和 /configuration/ui，这些路径都可能泄露信息。检查的时候，把这些全试一遍。我习惯用 curl 直接请求，看返回内容里有没有 swagger 或 openapi 字段。

最后说个真实场景。某次渗透测试，目标系统首页是个登录框，看起来挺正常。我随手请求 /swagger-ui/index.html，页面出来了。接口列表里有个 /api/v1/token/refresh，参数是 refreshToken。我随便填了个值，返回了“token 无效”。但响应头里带了 X-User-Id: 1001。这说明后端在解析 token 之前，就已经从某个地方读取了用户 ID。再结合 Swagger 里另一个 /api/v1/user/{ id} 接口，直接遍历 ID，拿到了全站用户信息。整个链条里，Swagger 提供了入口和参数格式，剩下的就是体力活。这种漏洞利用起来，成本低得吓人。

所以，下次部署前，花三十秒检查一下：/swagger-ui.html 能不能打开？/v2/api-docs 返回什么？如果答案是“能打开”和“一堆 JSON”，那你的系统已经在裸奔了。