Edu实战-某高校信息系统代码审计

声明

本文涉及的目标源码来源于前期信息收集阶段。出于安全与合规考虑，源码获取方式及相关细节不再赘述，仅对代码审计过程和漏洞分析进行分享，文中涉及的敏感信息均已进行脱敏处理。

在审计 API 模块时发现，大部分接口均继承自 BaseController，因此优先从该控制器入手分析认证逻辑

进入 BaseController 后发现定义了一处 Token 常量，但在当前文件中并未找到具体调用位置。随后继续跟踪控制器继承关系，在 RestController 中发现同样定义了相关 Token 参数。

进一步分析发现系统通过 token_check 方法进行身份校验。该方法会优先获取请求中的 private_token 参数，当参数不存在时则从 HTTP Header 中读取 Token 值，并与系统预设常量进行比较。

当校验通过时允许访问接口，否则返回 403 状态码。

为了验证漏洞影响，选择了一处用户信息查询接口进行测试。该接口会从缓存中读取用户数据并返回。

实际测试过程中发现，private_token 参数无法正常完成认证，而通过 Header 传递 Token 时能够成功访问接口，导致相关接口存在认证绕过风险。利用该问题可直接访问部分敏感接口，其中某接口可返回系统用户信息。由于用户 ID 并非连续分布，因此仅获取到部分用户数据。

获取用户数据后发现密码字段以密文形式存储，因此进一步分析登录模块的密码校验逻辑。

返回的密码字段为密文，继续跟进登录逻辑后发现其采用 ### + md5(md5(authcode + password)) 的方式存储。由于是 MD5 哈希而非可逆加密，因此无法直接从数据库中的密文还原出用户密码。

在审计其他业务接口时发现多个功能均会调用 check_user_id 方法进行用户身份校验，因此继续跟踪其实现逻辑。

分析发现 check_user_id 最终调用 getUserId 方法获取当前用户身份信息，而 UserId 属性则在控制器初始化阶段完成赋值。

继续跟踪构造流程，在 _initUser 方法中发现系统会从 HTTP Header 中读取 XX_DEVICE_TYPE 与 XX_TOKEN 参数，并将其直接拼接进入 SQL 查询语句。

由于相关参数缺少严格过滤与参数化处理，导致攻击者可以通过构造恶意 Header 数据影响 SQL 语句执行逻辑。

构造请求，目标返回异常数据库报错信息，由此确认注入点存在。随后通过报错回显方式验证漏洞并获取数据库相关信息。