2023年11月，东北大学东北大学秦皇岛分校的漏洞一名学生发现，学校教务系统的东北大学登录页面存在一个参数注入点。他在URL里把`uid=2023`改成`uid=2023' OR '1'='1`，漏洞页面直接跳转到了管理员后台。东北大学这个漏洞后来被提交到教育行业SRC平台，漏洞厂商确认评级为高危。东北大学事情本身不算大，漏洞但暴露出来的东北大学问题很典型：高校信息化系统的安全水位，比大多数人想象的漏洞要低得多。

我翻过几份公开的东北大学漏洞报告，东北大学相关的漏洞记录不止这一条。2022年有一份提交显示，东北大学某学院的漏洞选课系统存在越权访问——学生A登录后，把请求里的东北大学学号换成学生B的，就能看到B的课表和成绩。更早之前，图书馆的座位预约接口没有做频率限制，有人写了个脚本，十分钟刷了三百多个座位，系统没有任何拦截。这些漏洞单独看都不算致命，但串在一起，说明一个问题：开发时只考虑了功能跑通，没考虑有人会乱来。

为什么高校系统这么容易出问题？我接触过几个做过校园项目外包的开发者，他们的说法很一致：预算低、工期短、验收只看功能演示。一个选课系统可能只给两个月，前端后端一个人全包，安全测试基本靠“点几下没报错”就算过了。东北大学这个注入漏洞，代码层面看就是拼接SQL时没做参数化查询，属于最基础的错误。但这类错误在高校系统里反复出现，因为写代码的人可能压根没受过安全训练。

另一个原因是系统太老。东北大学有些院系的教务模块还是十年前用ASP写的，跑在Windows Server 2003上。这种环境本身就有大量已知漏洞，但没人敢动——怕改出问题影响毕业季。于是老系统继续跑，新系统往上叠，接口越开越多，权限越来越乱。2021年有个案例，某高校的旧版统一认证接口没下线，攻击者通过它绕过了新系统的双因素认证。东北大学有没有类似情况，公开信息里看不到，但从漏洞类型分布来看，老旧接口的遗留问题占了不少比例。

学生白帽子的作用在这件事里很关键。那个发现注入漏洞的学生后来在博客里写，他本来只是想改一下自己的选课结果，结果误打误撞进了后台。他没有继续深入，而是截了图提交给学校信息中心。信息中心一开始说“不可能”，让他别乱试。直到他把复现步骤发过去，对方才沉默，三天后打了补丁。这种互动模式在高校很常见：学生比管理员更懂系统，但缺乏正式的报告渠道。很多漏洞就这样被捂着，或者被少数人利用。

东北大学后来在2024年上线了新的统一身份认证平台，加了验证码和登录审计。但漏洞不会消失，只是换地方。只要高校信息化的建设逻辑不变——重功能轻安全、重建设轻运维、重采购轻培训——类似的事情还会发生。那个注入点被修了，下一个可能藏在成绩单打印接口里，或者藏在宿舍电费查询的某个参数里。没人知道。