CBSE数字化阅卷系统安全审计：客户端信任危机与访问控制失效

印度中央中等教育委员会（CBSE）的数字化阅卷系统 On-Screen Marking（OSM）在 2026 年 5 月遭遇重大安全披露。19 岁安全研究员 Nisarga Adhikary 公开的技术分析显示，这套承载数百万考生成绩评定的平台存在一系列基础性的架构缺陷 —— 从硬编码的主密码到完全依赖客户端的认证逻辑，暴露出教育科技领域在快速数字化过程中对安全基线的系统性忽视。

漏洞全景：从单点缺陷到架构性失守

这次披露的核心并非某个孤立的代码错误，而是一整套违背安全基本原则的设计决策。OSM 门户采用 Angular 构建，其前端 JavaScript bundle 对公众完全可访问。正是在这个任何人都能下载的文件中，研究人员发现了明文硬编码的 "主密码"—— 不是哈希值，不是密钥引用，而是直接嵌入客户端代码的原始字符串。

更危险的是这套密码的工作逻辑：当该主密码被输入登录表单时，系统会自动填充 OTP 字段并完全绕过正常的双因素认证流程。攻击者只需获取目标阅卷员的公开信息（用户 ID 和学校代码），配合这个可从 JS 文件中提取的主密码，即可直接登录任意账户进入评分仪表板。

OTP 验证机制的设计同样令人震惊。系统在执行认证时将 OTP 值包含在服务端响应中返回给浏览器，由客户端 JavaScript 将用户输入与该值进行比对。这意味着攻击者只需监控网络请求即可获取 OTP，或者完全跳过表单提交直接告知应用验证通过。安全控制运行在攻击者的机器上，本质上等同于没有控制。

访问控制的全面溃败

Angular 路由配置中完全缺失canActivate守卫，使得/dashboard、/evalscriptsview、/verificationdashboard等内部路由均可直接访问。研究人员演示了通过浏览器控制台注入伪造的 JWT 令牌和角色信息即可无认证进入系统内部页面的过程：

localStorage.setItem('jwtToken', 'dev-token-12345');
sessionStorage.setItem('role_id', '23');
// 直接导航至受保护页面
window.location.href = '/cbseevalweb/#/dashboard';

密码重置功能的设计进一步放大了风险。ChangePassword API 的请求体仅包含ValuatorID和pin_NewPassword两个字段，完全不验证旧密码。结合系统性的 IDOR（不安全直接对象引用）漏洞 —— 服务端从客户端可控的sessionStorage["eval"]中读取用户身份标识 —— 攻击者可以重置任意阅卷员的密码并完全接管其账户。

漏洞组合与攻击链

单独看每个缺陷都已足够严重，但当它们组合在一起时，形成了完整的账户接管攻击链：

1. 信息收集：用户 ID 和学校代码属于公开或半公开信息
2. 认证绕过：硬编码主密码 + 客户端 OTP 验证 = 无需合法凭证登录
3. 权限提升：伪造会话令牌绕过路由守卫进入内部系统
4. 账户接管：利用 IDOR 和密码重置 API 控制任意阅卷员账户
5. 数据篡改：以合法阅卷员身份查看、修改学生答卷评分

攻击者无需复杂的技术手段，仅需阅读前端代码并在浏览器开发者工具中修改几个值即可完成全部操作。正如研究人员所言："最困难的部分只是阅读一个 JavaScript 文件并在 DevTools 中编辑几个值。"

安全架构的根本性失误

这些漏洞共享同一个根本原因：将安全决策和敏感信息置于客户端代码中。现代 Web 应用的安全模型建立在 "永不信任客户端" 的基本原则之上 —— 浏览器环境完全受用户控制，任何发送到客户端的代码和数据都可被查看、修改和绕过。

OSM 系统的设计却反其道而行之：

• 密钥管理失败：主密码应存储于服务端密钥管理系统，绝不应出现在前端 bundle
• 认证逻辑错位：OTP 验证必须在服务端完成，客户端仅负责收集输入
• 授权机制缺失：路由守卫和 API 端点都应在服务端验证会话合法性
• 身份标识失控：用户身份必须从已认证的会话中派生，而非信任客户端提供的值

教育科技的安全基线

CBSE OSM 系统由 Coempt EduTeck Pvt Ltd 开发的 OnMark 平台提供技术支持，据称还被多个教育委员会和机构采用。这一事实使得漏洞的影响范围远超单一系统。

对于承载高敏感性数据的教育科技平台，以下安全基线应当成为硬性要求：

前端代码审计清单

• 搜索所有硬编码的凭证、API 密钥、加密密钥
• 验证敏感逻辑是否仅存在于服务端
• 检查是否存在可被篡改的客户端安全决策

认证授权架构原则

• 所有认证状态维护在服务端会话中
• 敏感操作（密码修改、评分提交）必须二次验证当前凭证
• API 端点对每个请求进行独立的权限校验

漏洞响应机制

• 建立明确的安全联系人渠道
• 对负责任的披露给予及时响应
• 高危漏洞应在 72 小时内启动热修复流程

披露时间线与响应滞后

研究人员于 2026 年 2 月 25 日首次向 CERT-In 报告漏洞，随后按要求提供了详细的技术说明和屏幕录制。CERT-In 的标准回复确认已登记案件并将采取适当行动，但后续数月内漏洞始终未得到实质性修复。直到 5 月博客公开引发媒体关注后，CBSE 才短暂下线门户进行紧急修补。

这一时间线揭示出关键基础设施漏洞响应中的结构性问题：缺乏有效的漏洞优先级评估机制、供应商与监管机构之间的协调不畅、以及对公共部门系统安全投入的系统性不足。

结语

CBSE OSM 事件并非孤立的代码质量问题，而是数字化公共服务在安全文化上的试金石。当数百万考生的学术命运依赖于一套将主密码硬编码在前端 JavaScript 中的系统时，暴露的不仅是技术债务，更是对整个教育数字化进程安全基线的拷问。对于正在推进类似系统的机构而言，这一案例提供了明确的警示：在将关键流程迁移到数字平台之前，必须首先建立起 "永不信任客户端" 的架构自觉。

资料来源

• Nisarga Adhikary 技术博客《Exposing Critical Vulnerabilities in CBSE's On-Screen Marking Portal》
• NDTV 报道《CBSE OSM Portal Had Critical Vulnerabilities》

security