登录页是门面，接口才是门：百万条人员信息泄露复盘

炫彩之星
炫彩之星

菜鸟学安全

2026年10月10日 23:26
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

这篇想告诉你的就一件事：登录页是门面，接口才是门。门面做得再规范，门没锁，数据就是敞开的——而门开着这件事，从登录页上一点都看不出来。背后却挂着一个不需要登录就能访问的查询接口。没有账号、没有凭证，一个 POST 请求，就能把库里百万条人员记录的姓名、身份证号、手机号、真人照片和 xx 全查出来。

本次渗透测试总计发现漏洞1个，其中高危漏洞1个，漏洞情况如下表：

接口未授权

漏洞描述：

通过接口未授权可以获取到所有日期的xx的身份证，手机号，姓名，真人照片和xx等敏感信息。

https://xx.xx.xx.xx/citywide/#/login

系统对外的入口只有一个登录页，看起来中规中矩。但登录页只是门面——前端页面能看到的数据，背后必然有接口在供数，而这些接口未必和登录框一样严格。

漏洞路径：

https://xx.xx.xx.xx/basic\_element\_control/outSeaPersonRegister/pageRegisterNew

从前端抓一遍请求，重点看哪些接口在没带鉴权凭证的情况下依然返回 200。上面这条请求就是答案：没有 Cookie、没有 Token、没有任何身份字段，服务端直接返回了 200 和完整数据。

Payload：

POST请求的json格式

https://xx.xx.xx.xx/basic\_element\_control/outSeaPersonRegister/pageRegisterNew

application/json

Fuzz接口所需的参数：

{

\"ncommitte\":null,

\"pageSize\":100,

\"pages\":1,

\"exist\":0,

\"startTime\":\"2026-xx 00:00:00\",

\"endTime\":\"2026-xx 23:59:59\",

\"userName\":\"\",

\"idCard\":\"\",

\"userPhone\":\"\",

\"marineType\":0

}

参数含义一目了然：startTime / endTime 控制时间范围，pageSize / pages 控制分页，userName / idCard / userPhone 还能按姓名、身份证号、手机号做精确筛选。

响应 code 200、msg 显示“查询成功”，data.records 展开就是一条条人员明细。

成功获取到2026年1月到2026年5月期间的xx万人左右的xx详细信息。包含身份证，姓名，手机号和真人相片等敏感信息。

返回的 total 字段直接暴露了库里的数据总量。而且 pageSize 没有服务端上限——把它从 100 改成 1000，服务端照单全收，总页数直接缩到十分之一，搬走全量的成本又低了一个数量级。

前端接口。

https://xx.xx.xx.xx/citywide/#/vesselBoard

前端看板上的人数统计，和接口返回的 total 完全一致——看板上的数字，就是这个未授权接口在喂。

xx人数查询页面。

人员明细列表里，头像、姓名、身份证号、手机号、xx、登记时间一应俱全，底部显示共 xx万条。这些数据本该登录之后才能看到。

修改日期为2020年到2026年至今为止最新的时间，可获取到xx万人左右的xx的所有身份证，手机号，姓名，真人照片和xx等敏感信息。

时间范围同样由客户端说了算：时间窗拉得越长，返回的 total 越大——想要多少数据，自己调参数就行。

xx人数查询页面。

总结一下：这次测试里没有 SQL 注入、没有文件上传、没有复杂的攻击链，唯一的突破口就是这一个“忘了做鉴权”的查询接口。但恰恰是这种看起来技术含量最低的漏洞，代价最大——一个接口，就是 xx万条敏感个人信息。

对做安全测试的同学：接手一套系统，先把前端所有接口抓一遍，重点标出那些没带鉴权凭证却依然返回数据的接口——它们往往不在功能菜单里，但它们在数据层是敞开的。这类系统的数据越敏感，越不该把安全寄托在“没人知道接口地址”上——接口地址就写在前端代码里，谁都能看到。

如果这篇对你有用，欢迎点赞在看；你在实战里遇到过类似的“一个接口定胜负”的案例吗？评论区聊聊。