API信息泄露漏洞挖掘：从一条报错日志到整个用户库

某次渗透测试，信息泄我随手在目标站点的露漏登录接口后面加了个`/v1/users`，服务器返回了200和一段JSON。洞挖里面整整齐齐躺着用户名、信息泄手机号、露漏邮箱，洞挖甚至密码的信息泄MD5。这活儿三分钟就干完了——不是露漏因为我厉害，是洞挖开发者把API文档里的生产环境地址忘删了。

API信息泄露和传统Web漏洞不一样。信息泄SQL注入好歹要跟数据库搏斗几个来回，露漏越权得慢慢试参数。洞挖API泄露往往是信息泄开发者自己把门敞开的，你只需要找到那扇没上锁的露漏侧门。最常见的洞挖是调试接口没关，比如`/debug`、`/swagger-ui.html`、`/actuator`这些路径，直接暴露了所有端点定义和参数结构。

有个案例我记得很清楚。某金融APP的转账接口，用`userId`参数区分用户。我试着把参数改成另一个数字，响应居然返回了那个人的交易明细。没有鉴权校验，没有Token验证，甚至没有基本的请求频率限制。开发者的逻辑可能是“反正用户看不到别人的ID”，但ID这东西，爬虫几分钟就能枚举完。

挖掘这类漏洞有个笨办法但特别有效——抓包。把APP或网页的所有请求都过一遍Burp Suite，重点看响应里的字段。有时候接口会把内部信息塞在响应头里，比如`X-Debug-Message`带着数据库查询语句。更隐蔽的是错误处理不当，你故意传个畸形参数，服务器把完整堆栈抛出来，里面藏着内网IP、文件路径、第三方服务的密钥。

另一个高频泄露点藏在“过度分享”的接口里。开发为了前端方便，直接返回整个数据表对象，包括`is_admin`、`password_hash`这类不该出现的字段。前端不用这些数据，但接口照常返回。这种问题在GraphQL里更严重，因为查询语言本身就允许客户端指定返回字段，如果没做白名单，`query{ user(id:1){ password}}`就能直接命中。

说个反直觉的观察：很多API泄露不是技术问题，是管理问题。我见过一个内部API网关，所有微服务的密钥都写死在同一个配置文件里，而且这个文件被某个开发者不小心提交到了公开的GitHub仓库。你甚至不需要攻击API本身，去代码托管平台搜`api_key`加公司名，分分钟拿到生产环境的凭证。

挖掘时别光盯着主域名。子域名、测试环境、旧版本API往往是重灾区。很多公司上线新版本后，旧接口没下线，仍然带着完整功能。我就遇到过某个电商的`/api/v2/orders`是新的，但`/api/v1/orders`还能用，而且v1版本没有做权限校验——因为当初开发时觉得“反正要废弃了”。

修复方案其实不复杂：所有接口默认拒绝，按需开放；返回字段用DTO层过滤，别直接序列化数据实体；错误信息统一封装，不向客户端暴露堆栈。但最关键的还是流程——API上线前必须有安全评审，测试环境与生产环境隔离，密钥定期轮换。可惜多数公司把API当内部工具，觉得“没人会闲着来打”。

现实是，攻击者比你想的更闲。他们扫全网IP段，跑目录字典，用自动化工具遍历每个可能的路径。你的API只要暴露一个未授权接口，整个数据库就裸奔了。这活儿不需要高深技术，只需要耐心和一点侦查意识——就像我开头说的，三分钟搞定一个系统，有时候真不是夸张。

(责任编辑：探索)