检测到目标网站使用swagger api漏洞

一个普通的检测周二下午，我随手点开某个后台管理系统的到目洞登录页，F12打开开发者工具，标网Network面板里一个请求引起了我的站使注意——/v2/api-docs。返回的检测JSON数据里躺着整个系统的接口清单：用户管理、订单查询、到目洞文件上传，标网甚至还有几个标注了"internal"的站使内部接口。这就是检测Swagger UI没关的典型现场。

Swagger本身不是到目洞漏洞。它是标网API文档工具，方便前后端联调。站使问题出在部署环节——开发阶段开着方便，检测上线时忘了关。到目洞攻击者拿到/swagger-ui.html这个页面，标网等于拿到了一份完整的接口说明书，参数格式、请求方式、认证要求，全写在上面。

我见过最离谱的一个案例。某电商平台的生产环境，Swagger页面直接暴露在公网，里面有个/api/v1/user/delete接口，参数只需要传用户ID。没有鉴权标注，没有权限校验说明。我试着构造了一个DELETE请求，返回200。当然我没真的删，只是把ID改成了一个不存在的值。但那个响应码已经说明了一切。

这类问题有多普遍？说个数据。我手头有一个自己写的扫描脚本，逻辑很简单：遍历常见路径，匹配Swagger特征字符串。过去半年里，我拿它扫了大概两千个国内中小型企业的域名，命中率在12%左右。也就是说，每八个网站，就有一个把Swagger暴露在外。金融、医疗、物流，行业分布很散。

为什么关不掉？我跟几个开发聊过。一个说："测试环境要用的，生产环境忘了改配置。"另一个说："网关层做了IP白名单，外网访问不到。"我当场用手机4G网络打开了他的Swagger页面。他愣了几秒，说："可能是Nginx配置没生效。"

更麻烦的是，Swagger暴露往往不是孤立问题。接口清单里能看到什么？/actuator/env、/druid/index.html、/v2/api-docs?group=internal。这些路径串起来，攻击者能拼出一张完整的攻击地图。Spring Boot Actuator如果也没关，环境变量里的数据库密码、Redis连接串，直接明文躺在那里。

有人会说："接口有鉴权，看到了也调不通。"这话对一半。确实，大部分业务接口需要Token。但Swagger里经常混着一些"漏网之鱼"——登录接口、验证码发送接口、文件上传接口。这些接口要么不需要鉴权，要么鉴权逻辑有缺陷。我见过一个短信发送接口，Swagger里标注的参数是phone和content，没有频率限制。拿它刷短信，一晚上能烧掉几千块。

怎么判断自己中招了？直接访问/swagger-ui.html或者/swagger-ui/index.html。如果页面正常加载，看到一堆接口列表，那就是了。别只看首页，试试/v2/api-docs，这个JSON文件才是核心。有些系统把UI关了，但api-docs没关，照样泄露。

修复方案不复杂。生产环境直接禁用Swagger，Spring Boot里加个@Profile("!prod")注解，或者用springfox.documentation.enabled=false。如果非要在生产环境保留文档，至少加个HTTP Basic认证，别让裸奔。Nginx层做路径拦截也行，但记得测试，别只拦了/swagger-ui，漏了/v2/api-docs。

我写这篇文章的时候，又随手扫了几个域名。其中一个返回的Swagger JSON里，有个接口叫/api/admin/reset-password，参数是userId和newPassword。没有鉴权头。我关掉浏览器，没再往下试。有些门开着，不代表你应该走进去。但攻击者不会这么想。