作为一名在校大学生兼网络安全爱好者，给自家的系统做体检一直是我最大的乐趣之一。最近，在一次例行的授权渗透测试中，我将目光锁定在了某高校的研究生招生信息系统上。
原本以为这只是一次平平无奇的常规打卡，没想到在层层受阻后，竟然挖出了一套“组合拳”。今天，就和各位师傅分享一下这次心跳加速的实战经历。
0x01 故事背景
研究生招生系统，可以说是高校里最核心、数据最敏感的业务系统之一。姓名、身份证、成绩单、科研成果……这里面沉淀的数据价值不言而喻。
当我打开系统的登录页时，一阵隐隐的兴奋涌上心头。它不仅承载着庞大的业务逻辑，更重要的是，这套系统没有接入学校统一的 SSO（单点登录）！对于渗透测试来说，独立的注册和鉴权模块往往意味着更大的攻击面。
好戏，就从点击“新用户注册”那一刻开始了。
0x02 信息收集
注册好账号满怀期待地登进去，系统却给我泼了一盆冷水：页面赫然显示“不在报名时段”。
“就这么结束了？？”作为一名热爱折腾的大学生，我的字典里可没有“放弃”两个字。
既然业务流程被时间锁死了，那路由和接口呢？直觉告诉我，前端的限制往往是脆弱的。我直接掏出祖传的 Fuzz 字典，开始对目录进行爆破。
渗透笔记：寻找路由规律
经过一番观察和目录扫描，我发现系统虽然在主入口拦截了操作，但底层的路由规则非常规整。
比如：
https://gmis.example.edu.cn/php/bm/SQXX_Index.php
https://gmis.example.edu.cn/php/bm/TMS_Index.php
相信经验丰富的师傅们已经看出来了，这里的命名规范是 XXXX_Index.php
顺着这个线索，结合 Fuzz 的结果，我成功绕过了“不在报名时段”的逻辑，直接找到了研究生报名的真实入口！一个庞大的信息填报表单展现在我面前
0x03 漏洞利用
进入表单后，我立刻锁定了渗透测试的“兵家必争之地”——文件上传点
1. 消失的文件与隐藏的 SQL 注入
在照片和成绩单上传处，由于当前确实不在正式的报名阶段，前端虽然有上传按钮，但我尝试抓包后发现，根本抓取不到实际的文件内容参数，相关的核心上传接口似乎在后端被彻底关闭了。
本以为这条路断了，但我没有放弃对接口边缘参数的测试。在翻阅历史请求时，我注意到了这样一个 GET 接口：
/php/bm/Upload.php?Type=ZP
Type=ZP？这个参数看起来太像直接拼接到 SQL 语句里去查表或者查配置的了。我顺手丢进了 SQLMap。
原本没抱太大希望，但却意外出货了：
一处高危的 SQL 注入漏洞诞生了。后端使用的是 Microsoft SQL Server，且不仅是这一个接口，随后我在 /php/bm/TMS_apply.php?Opt=Save 接口的 Opt 参数中同样发现了注入点。开发者显然在这些辅助接口中忽略了参数化查询
2. “掩耳盗铃”的前端 XSS 过滤
拿到了数据库层面的突破口后，我决定回到业务逻辑层继续挖掘。
在仔细填写报名表（如工作简历、获奖情况等）时，我尝试在文本框中插入了经典的 XSS Payload：
<script>alert(1)</script>
提交时，页面突然毫无反应，随后发现前端的 JavaScript 自动将敏感字符（如 <、>、script）给过滤掉了。
思路转换：
既然是前端 JS 的过滤，那不就等于“防君子不防小黑子”吗？在前后端分离不彻底或后端校验缺失的系统里，这种防御简直形同虚设。
我果断打开 Burp Suite，拦截了提交表单的 POST 请求。在 Repeater 模块中，我绕过前端，直接将 Payload 注入到请求体参数中并发送。
当然burpsuite页面没来得及截图，这里直接放上成功触发xss的截图
清脆的弹窗 666 跃然屏上。存储型 XSS 触发成功！
0x04 危害影响
至此，我已经手握 SQL 注入 和 存储型 XSS 两张底牌。如果这不是一次授权测试，后果将不堪设想：
- 拖库与数据泄露：利用 SQL 注入，攻击者可以轻易脱出包含万千考生身份证、联系方式、报考志愿的 TargetData 等核心数据库。在黑产眼中，这些精准的个人信息价值极高。
- 凭证窃取与后台接管：通过在简历表中植入存储型 XSS 恶意脚本，当高校的招生办老师在后台审核这名“考生”的材料时，就会神不知鬼不觉地触发脚本，导致管理员的 Cookie/Session 被窃取，攻击者将直接接管招生后台，甚至可以篡改录取状态。
这对于一所高校的声誉和考生的权益来说，绝对是毁灭性的打击。
0x05 防御与反思
从攻击者的快感中抽离出来，作为信息办的助理，我同样需要思考如何堵上这些窟窿。这次挖掘暴露出该系统在架构和开发规范上的几个典型缺陷：
- Root Cause 1：过度信任客户端。 无论是“不在报名时段”的拦截，还是 XSS 的字符过滤，都仅仅停留在前端。安全铁律：永远不要相信用户的输入。 所有的业务时间校验和危险字符过滤，必须在服务器端重新进行严格的检查。
- Root Cause 2：直接拼接 SQL 语句。 PHP 在处理 Upload.php?Type=ZP 等老旧接口时，显然直接将 GET/POST 参数拼接进了 SQL 查询中。修复建议非常明确：全面排查代码，废弃直接拼接，强制使用 预编译语句 (Prepared Statements) 或现代的 ORM 框架。
- Root Cause 3：缺乏 XSS 纵深防御。 后端在入库和出库时均未对特殊符号进行 HTML 实体转义（htmlspecialchars）。同时，系统未配置 HttpOnly Cookie 属性，也未开启 CSP (Content Security Policy)，导致 XSS 攻击极易转化为会话劫持。
写在最后：
技术是一把双刃剑，渗透测试的目的永远是为了更好地建设。当把这份充满着 Payload 和红字的漏洞报告提交给老师时，我深知，这不只是一次技术的狂欢，更是作为一名安全方向大学生守护母校数字边界的责任。