从登录绕过到越权泄露：1227 条校友敏感信息全量失守

原创

炫彩之星
炫彩之星

菜鸟学安全

2026年10月31日 20:17
广东

去阅读

在小程序的登录框里随便敲了一组用户名和密码，提示登录失败，页面却跳了进去；再点一下「校友」，全院 1227 名校友的手机号、出生日期、工作地点，排着队出现在列表里。

问题的根子在前后的错位上：前端用「账户正在审核中」的提示把人拦在校友功能外面，后端接口却不校验账户的审核状态和数据权限——界面拦得住人，请求拦不住数据。

在一次攻防项目中，我们发现某学院小程序存在 1 项高危漏洞：越权导致敏感信息泄露，实测可获取 1227 条校友个人信息。

越权导致敏感信息泄露：登录失败也能看全部校友

漏洞地址： GET https://xx.xx.xx.xx/api/system/alumni.info/page?pageNum=1&pageSize=10&name=&alumniCode=（需登录态 Token，未校验账户审核状态）

怎么发现的： 目标是一次攻防项目中的某学院官方小程序。正常注册流程走到「校友」功能时被拦——提示「账户正在审核中」。这个提示本身是个信号：系统知道该拦人。顺着「审核中」这个状态往下试，就成了这条链子的起点。

/api/system/alumni.info/page 是校友信息的分页查询接口，按页返回校友的姓名、手机号、出生日期、工作地点等字段。正常来说，一个「审核中」的账户不应该有任何查看校友数据的权限。

先看正常路径。校友功能点进去，直接被拦，提示账户正在审核中：

换个思路。进「我的」，走账户密码登录，用户名和密码随便填一组：

登录失败了，但小程序没有停在登录页，而是照常进行了跳转：

跳转之后再点一次「校友」——这次没拦，校友列表直接出来了：

前后端的分歧就在这里：前端把「审核中」的用户拦在界面外，后端却对同一个账户全量放行。抓包看请求，正是那个校友分页接口：

【请求包】
GET /api/system/alumni.info/page?pageNum=1&pageSize=10&name=&alumniCode= HTTP/1.1
Host: xx.xx.xx.xx
Authorization: <未审核账户的登录态 Token>

（Token 请求头以实际抓包为准，此处为复现示意。）

响应里的内容远比前端页面显示的多——total 为 1227，每条记录都带着手机号、出生日期、工作地点这些本不应显示在前端的个人敏感信息：

【响应包（关键字段）】
HTTP/1.1 200 OK

total: 1227
records: 每条记录含姓名、手机号、出生日期、工作地点等个人敏感字段（其余字段略，完整数据见下图）

返回小程序，再点一次校友功能点，页面成功渲染出所有校友的个人敏感信息：

接口返回 1227 条校友信息（需登录小程序获取 Token 查看）：

全院 1227 名校友的手机号，全部在列：

全院 1227 条校友记录——姓名、手机号、出生日期、工作地点——对一个随便输错密码就能进来的访客全量放行。手机号 + 出生日期 + 工作单位三件套，足够支撑撞库、精准诈骗、定向社工等下游攻击；对一所学院来说，这是全量校友的个人隐私在一次随手尝试中失守。

写在最后

回看这条链子，没有一个高危 CVE，也没有复杂的绕过技巧：一次登录失败后的跳转，一个不问账户状态的后端接口。前端用「审核中」的提示尽职尽责地拦人，后端却把数据原样给了出去——权限控制做在了界面上，没做在服务端。

这也是前后端回显不一致类漏洞的共同点：前端拦截只是体验层，真正的权限边界必须在服务端重新回答一遍——这个账户是什么状态、这条数据该不该给这个人看。少问任何一句，界面上拦住的就只是界面。

攻防项目的意义，不是证明系统有多脆弱，而是在真实攻击者之前把问题找出来。文中学院名称、域名与人员信息均已脱敏，仅用于安全研究与防御参考。