教育系统安全实战：从SQL注入到越权漏洞的渗透测试与修复

1. 项目概述：一次对教育数字化底线的“体检”

最近几年，教育信息化进程加速，各类在线教学、考试、阅卷系统如雨后春笋般涌现。作为一名长期关注应用安全的研究者，我习惯性地会对身边这些新上线的系统保持一份“好奇心”。这次的目标，是一个在本地多所学校推广使用的“网上阅卷系统”。它号称能实现试卷扫描、客观题自动判分、主观题在线批阅、成绩统计分析全流程数字化，听起来非常高效便捷。但我的直觉告诉我，越是这种承载着高利害关系（学生成绩、教师评价）的系统，其安全防线可能越脆弱，因为开发者的首要目标往往是功能实现和用户体验，安全常常被置于次要位置。这次“挖掘”，更像是一次非官方的、出于责任心的安全“体检”，我想看看在光鲜的界面背后，是否存在可能被利用的薄弱环节。

网上阅卷系统本质上是一个B/S架构的Web应用，通常涉及教师、学生（或考生）、管理员等多种角色，业务流程复杂，包含上传、批改、查询、统计等多个环节。任何一个环节的逻辑设计疏忽或技术实现缺陷，都可能演变为严重的安全漏洞。我的目标很明确：在不影响系统正常服务、不触碰真实数据的前提下，以授权测试或研究的心态，尝试发现其中可能存在的安全隐患，并理解其成因。这不仅能帮助相关方提升安全意识，对于安全从业者而言，也是一次绝佳的实战学习机会，可以深入理解业务逻辑与安全技术的交汇点。

2. 前期侦察与信息收集：摸清“战场”地形

在动手测试之前，盲目的扫描和攻击是低效且危险的。我的第一步永远是尽可能多地收集目标信息，这就像战前侦察，了解对方的兵力部署（技术架构）和防御工事（安全措施）。

2.1 目标系统指纹识别

首先，我通过浏览器访问了系统的登录页面。查看网页源代码，是获取基础信息的捷径。我迅速发现了几个关键线索：

1. 前端框架：页面中引用了特定的JavaScript库和CSS文件，例如vue.js和element-ui，这暗示前端可能基于Vue.js框架开发。现代前端框架本身安全性较高，但与之交互的后端API是重点。
2. HTTP响应头：通过浏览器开发者工具或curl命令查看服务器返回的HTTP头。我发现了Server: nginx/1.18.0和X-Powered-By: PHP/7.4.33。这直接揭示了Web服务器是Nginx，后端语言是PHP。PHP版本是7.4.33，这是一个已经停止官方安全维护的版本（EOL），这本身就是一个潜在的风险点，意味着已知的公开漏洞可能无法得到官方补丁。
3. URL结构与参数：浏览了几个功能页面，发现URL模式多为/index.php?m=admin&c=score&a=query或/api/student/getList?page=1&limit=20。前者是典型的基于MVC框架（如ThinkPHP）的URL路由形式，后者则是更现代化的RESTful风格API。混合架构可能意味着系统是逐步迭代开发的，不同模块的安全水平可能不一致。

注意：信息收集阶段的所有操作都应限制在公开可访问的页面上，避免触发入侵检测系统（IDS/WAF）。使用curl -I（获取头部）、whatweb或Wappalyzer浏览器插件都是常用且低调的方法。

2.2 目录与接口探测

有了基础信息，下一步是发现更多隐藏的入口点。我使用了dirsearch工具，配合一个适中的字典，对目标域名进行目录和文件扫描。目的是寻找：

• 备份文件（如.bak,.zip,.tar.gz,wwwroot.zip）
• 配置文件（如.env,config.inc.php）
• 管理后台入口（如/admin/,/manage/,/backend/）
• 未引用的API接口文档（如/swagger/,/api-doc/）
• 测试或示例文件

扫描结果中，除了已知的功能页面，我发现了一个/phpinfo.php文件。访问后，果然是一个未删除的phpinfo()信息页。这相当于一张系统的“体检报告”，暴露了大量敏感信息：PHP配置（如allow_url_include是否开启）、已安装的扩展、服务器路径、环境变量等。这是一个低级但极其危险的错误配置，我立即记录下这个发现。同时，还发现了一个/upload/目录，直接列出了所有上传的文件，这属于目录遍历漏洞，可能泄露用户上传的试卷图片等敏感资料。

2.3 账户体系与业务逻辑初探

为了理解业务逻辑，我尝试注册了一个测试账号（如果开放注册），或者分析登录、找回密码等流程。这个系统需要学校统一分配账号，因此我转而仔细研究其登录和会话管理机制。 通过拦截登录请求，我发现登录成功后，服务器返回了一个名为auth_token的字段，并在后续请求中，客户端通过在HTTP请求头Authorization: Bearer <token>的方式携带该令牌。这是JWT（JSON Web Token）或无状态会话的常见做法。我需要验证这个Token的强度：是否可预测？是否过期时间过长？是否在注销后依然有效？

3. 漏洞挖掘实战：从外围到核心的渗透

信息收集完毕后，我心中已经绘制了一张初步的“攻击面地图”。接下来，就是按照风险优先级，逐一进行测试验证。

3.1 入口点漏洞：SQL注入与文件上传

SQL注入测试：我选择了几个看似最有可能存在注入的点：登录表单、成绩查询接口、用户信息查询接口。使用Burp Suite拦截这些请求，对每一个参数（无论是GET还是POST）进行篡改。

• 经典探测：在参数值后附加单引号'，观察返回错误。在查询学生列表的API/api/student/getList?name=test中，我将name参数改为test'，返回了数据库错误信息，明确提到了SQL语法错误。这证实了存在SQL注入漏洞。
• 漏洞利用：进一步，我使用sqlmap工具进行自动化验证和利用。命令如下：

  sqlmap -u "http://target.com/api/student/getList?name=test" --batch --dbs

  很快，sqlmap成功识别出注入点，并获取了数据库列表。我发现系统使用了MySQL，库名包含exam_db。通过注入，我能够枚举表名、字段名，甚至提取数据。这里暴露的根本问题是，后端在拼接SQL语句时，未对用户输入进行有效的过滤或使用预编译语句（Prepared Statements）。

文件上传漏洞测试：我找到了试卷图片上传的功能点。尝试上传一个正常的.jpg图片，成功。然后，我尝试进行绕过：

1. 修改文件扩展名：将一句话木马文件shell.php重命名为shell.jpg，然后通过Burp修改上传数据包中的filename为shell.php。系统后端仅检查了文件名，未校验文件内容，上传成功。
2. 双扩展名绕过：上传shell.jpg.php。
3. Content-Type绕过：将shell.php的Content-Type改为image/jpeg。 经过测试，其中一种方式成功上传了PHP文件，并且可以通过浏览器直接访问/upload/shell.php来执行任意代码。这结合之前发现的目录遍历，危害极大，攻击者可以直接获取服务器控制权。

3.2 业务逻辑漏洞：越权与数据篡改

业务逻辑漏洞往往比技术漏洞更隐蔽，也更难通过自动化工具发现，需要深入理解业务流程。

水平越权：假设我以学生A的身份登录，我的用户ID是1001。系统有一个查看“我的试卷详情”的接口：/api/paper/detail?paper_id=5001。我尝试将paper_id参数改为5002（推测是学生B的试卷），请求竟然成功返回了学生B的试卷详情和分数。这说明系统在验证用户权限时，只检查了会话是否有效，但没有校验当前用户是否有权访问paper_id=5002这份资源。这就是典型的不安全的直接对象引用（IDOR）。

垂直越权：我注意到，普通教师和管理员可能共用一套前端代码，权限控制仅靠前端菜单隐藏或按钮禁用。通过拦截普通教师登录后的请求，我分析其API返回的菜单数据，发现其中包含了一个标记为hidden: true的管理员功能菜单项。我直接手动构造访问该隐藏功能对应API的请求（例如，添加系统用户的API/api/admin/user/add），由于后端缺乏对接口级别的角色校验，该请求被执行成功。这属于功能级访问控制缺失。

分数篡改逻辑漏洞：这是网上阅卷系统最核心、最敏感的业务。我仔细测试了教师批阅后提交分数的流程。拦截提交分数的POST请求，发现其数据结构类似于：

{ "exam_id": 2024001, "student_id": 1001, "questions": [ {"qid": 1, "score": 5}, {"qid": 2, "score": 10}, ... ], "total_score": 150 }

我尝试修改了student_id为其他学生，或者修改某个题目的score为超出满分限制的值（如满分10分，我提交15分）。测试发现：

1. 修改student_id后，分数被错误地记录到了另一个学生名下（严重的越权数据篡改）。
2. 提交超限分数时，后端竟然接受了，并在总分计算中使用了这个非法值。这说明后端缺乏关键的业务规则校验：一是未二次确认分数归属，二是未对单项分数进行合法性校验（如是否在0-满分之间）。

3.3 会话与认证漏洞：Token的安全性问题

回顾登录时获取的auth_token。我使用jwt.io这个在线工具对其进行解码（无需密钥，仅查看结构）。发现它是一个简单的JWT，包含用户ID、角色和过期时间（exp），但签名部分使用的是弱密钥或默认密钥。更严重的是，exp字段设置得非常遥远（比如一年后），这意味着Token一旦泄露，在很长一段时间内都有效。 我尝试了以下攻击：

• Token篡改：由于怀疑密钥强度弱，我使用工具jwt_tool尝试对Token进行暴力破解或已知弱密钥测试，试图伪造一个高权限（如管理员）的Token。
• 注销机制测试：在客户端点击“退出登录”后，我依然用旧的Token去访问需要认证的API，发现仍然可以成功访问。这说明服务端没有有效的Token吊销机制，会话管理是有状态的（可能在服务端存储了Token白名单），但注销时并未从白名单中移除该Token。

4. 漏洞成因深度分析与修复建议

发现漏洞只是第一步，理解其背后的成因，才能提出有效的修复方案，这也是安全研究的价值所在。

4.1 技术层面成因

1. 安全意识缺失与安全开发流程（SDL）未落地：phpinfo.php文件遗留、目录列表开启，这些都是运维和开发中最低级的错误，表明项目从上线到运维，缺乏基本的安全检查和清理流程。SQL注入和文件上传漏洞则直接指向开发人员未经过安全编码培训，对用户输入持有绝对信任。
2. 依赖过时且有风险的组件：PHP 7.4已停止维护，意味着已知的漏洞（如某些特定版本的PHP漏洞）无法通过官方升级修复，需要自行 backport 补丁或承担风险。
3. 权限校验逻辑设计缺陷：这是业务逻辑漏洞的根源。系统采用了“通过隐藏来实现安全”的前端控制思维，而忽视了最根本的“服务端每次请求都必须进行权限校验”的原则。校验逻辑分散、不统一，甚至缺失。
4. 会话管理不当：JWT使用弱密钥、超长过期时间、无吊销机制，使得Token一旦泄露即造成持久性风险。JWT适用于无状态场景，但系统业务明显需要状态管理（如强制下线、注销），技术选型与业务需求不匹配。

4.2 修复方案建议

针对以上漏洞，我整理了一份简要的修复建议清单：

5. 反思与总结：教育类系统安全的特殊性

这次对网上阅卷系统的漏洞挖掘，让我对教育行业应用安全有了更深的体会。这类系统有几个显著特点，也放大了安全风险：

1. 数据敏感性极高：学生成绩、个人信息属于高度敏感数据。一旦泄露或篡改，不仅侵犯个人隐私，还可能影响升学、评价等重大利益，引发严重的社会问题。
2. 用户群体庞大且复杂：用户包括学生、教师、家长、管理员，角色多样，权限模型复杂。很容易在权限设计上出现疏漏，导致越权。
3. 开发运维压力大：教育信息化项目往往预算有限、工期紧张。承建方可能是一些中小型软件公司，其安全开发能力和安全意识参差不齐。学校作为使用方，也普遍缺乏专业的安全运维人员。
4. 等保合规要求：这类系统通常需要满足网络安全等级保护（等保）的要求。其中很多中高危漏洞（如SQL注入、越权）是等保测评中的“一票否决”项。

因此，对于教育类系统的安全建设，绝不能停留在“事后打补丁”的阶段。必须从软件开发生命周期（SDLC）的源头入手，将安全需求纳入设计，对开发人员进行安全编码培训，在上线前进行严格的安全测试（白盒+黑盒+渗透测试），并建立常态化的安全监控和应急响应机制。

对我个人而言，这次实战是一次宝贵的经验积累。它再次印证了“漏洞往往存在于复杂业务的结合部”这一观点。自动化工具能发现常见的技术漏洞，但那些深藏于业务流程中的逻辑漏洞，更需要测试者具备“攻击者思维”，去理解业务，去问“如果我是恶意用户，我会怎么滥用这个功能？”。保持这份好奇心和对细节的执着，是安全研究者最重要的品质之一。最后，所有这类测试必须在获得明确授权的前提下进行，并将发现的问题通过合规渠道（如SRC平台）上报，这才是负责任的安全研究之道。