swaggerapi未授权访问漏洞原理扫描

Swagger API未授权访问漏洞原理扫描

打开一个目标站点，未授问漏路径拼上 /swagger-ui.html，权访页面直接弹出了整套API接口列表。洞原这不是理扫什么新鲜事，但每次遇到还是未授问漏让人心里一紧——所有接口的参数、请求方式、权访甚至认证头长什么样，洞原全摆在那里。理扫Swagger UI 本来是未授问漏为了方便开发调试用的，问题在于很多人把它连同生产环境一起发布了。权访

这个漏洞的洞原本质不复杂。Swagger 是理扫一套 API 文档生成工具，后端集成 Swagger 后会自动暴露几个端点：/swagger-ui.html、未授问漏/v2/api-docs、权访/swagger-resources、洞原/webjars/springfox-swagger-ui/ 等等。这些路径默认不带任何鉴权。攻击者不需要登录，不需要 token，直接访问就能拿到完整的接口清单。更麻烦的是，/v2/api-docs 返回的是 JSON 格式的接口定义，里面包含每个接口的 URL、HTTP 方法、参数名、参数类型、是否必填。有了这些信息，下一步就是逐个接口测试未授权访问、越权、SQL注入、SSRF。

我扫过不少站点，发现 Swagger 暴露的概率比想象中高。尤其是国内一些中大型企业的后台管理系统，用 Spring Boot 搭的，开发阶段为了方便，Swagger 一直开着，上线时忘了关。还有些是测试环境直接映射到了公网。有一次碰到一个电商后台，/v2/api-docs 直接返回了 200 多条接口定义，其中 /api/user/list 这个接口不带任何认证参数就能调用，返回了所有用户的手机号和邮箱。这不是理论上的风险，是实打实的数据泄露。

扫描这件事，手工做效率太低。通常写个脚本，维护一个字典，把常见的 Swagger 路径塞进去，逐个请求，看返回状态码和内容特征。状态码 200 且响应体里包含 "swagger"、"api-docs"、"paths" 这些关键字，基本就能确认。有些站点做了重定向，比如 /swagger-ui.html 跳转到登录页，这种情况不算漏洞，但 /v2/api-docs 可能还是通的，所以两个路径要分开判断。另外要注意 Swagger 的版本差异，Springfox 和 SpringDoc 的路径不太一样，SpringDoc 用的是 /swagger-ui/index.html 和 /v3/api-docs。

工具方面，Burp Suite 的被动扫描插件能自动发现 Swagger 路径，但主动扫描更靠谱。我自己习惯用 ffuf 或者 dirsearch 跑一遍字典，然后手动验证。网上也有现成的 Nuclei 模板，匹配规则写得比较完善，直接跑就行。不过工具终归是辅助，关键还是得理解这个漏洞的成因——不是 Swagger 本身有漏洞，是开发者把它暴露在了不该暴露的地方。

修复方式也简单。生产环境直接关掉 Swagger，Spring Boot 里加个 @Profile("!prod") 注解就行。如果确实需要在线文档，加一层认证，Spring Security 配置里把 /swagger-ui/** 和 /v2/api-docs 纳入权限控制。再退一步，至少用 Nginx 做 IP 白名单，只允许内网访问。最怕的是那种“我知道有风险但先这样吧”的心态，等数据被拖了再补救，成本完全不一样。

扫描这个动作本身不复杂，复杂的是面对一堆暴露的接口时，能不能判断出哪些是真正的风险点。返回了接口列表不等于有漏洞，但如果列表里出现了 /admin/deleteUser 这种路径，而且不带认证就能调，那就不是“可能存在风险”的问题了。