揭露CBSE屏幕标记门户的关键漏洞

# 揭露 CBSE 在线阅卷门户的关键漏洞：从认证绕过到完全账户接管 — ni5arga 来源：https://ni5arga.com/blog/posts/hacking-cbse 我最初用一次性 Reddit 账号在 r/CBSE 上发了一个粗略的漏洞描述，但觉得还是自己博客上写一篇正式的文章更合适。讨论这个问题的推文（X 帖子）可以在这里找到：https://x.com/ni5arga/status/2057831536586850422。 这些漏洞最初是在 2026 年 2 月 25 日发现的，并已及时报告给 CERT-In。 ### 什么是 CBSE 和在线阅卷？ 中央中等教育委员会（CBSE）是印度最大的国家教育委员会之一。它隶属于印度政府，每年负责组织十年级和十二年级等大型考试，涉及数百万学生。 CBSE 在印度国内拥有超过 28,000 所附属学校，在国外还有数百所，使其成为该国最具影响力的教育机构之一。每年，作为考试流程的一部分，成千上万的教师和考官需要评估数百万份答卷。 为了提高效率，CBSE 已开始将十二年级考试迁移到数字化在线阅卷（OSM）系统（公告：https://www.cbse.gov.in/cbsenew/documents/OSM_Class%20XII_09022026.pdf）。考官不再检查纸质答卷，而是登录一个在线门户，在那里分配扫描后的答题卡进行评估。 由于该平台有大量评估人员使用，并处理敏感的学业数据，其安全性至关重要。该平台似乎由 Coempt EduTeck Pvt Ltd 开发，同一套 OnMark 平台也被多个委员会及其他机构使用。 在进行探查时，我发现了 OSM 门户中的几个严重漏洞，这些漏洞可能导致考官账户被完全接管。利用这些漏洞的人还可能篡改或破坏评分过程，直接威胁考试评分的公正性。 在发布这篇博客之前，我已向 CERT-In 报告了所有问题。 邮件1 ### 发现漏洞 先说说我的背景。我是一名爱好网络安全的研究员，今年刚完成十二年级考试。我之前出于兴趣做过一些漏洞赏金和安全研究的工作，所以当 CBSE 推出 OSM 且我注意到门户链接完全公开时，我的好奇心战胜了我。 我打开了在线阅卷门户，开始摆弄 HTTP 请求以及我能看到的其他所有东西。 登录页面要求提供三项信息：用户 ID、学校代码和密码，然后还需要一个 OTP 步骤。那个页面看起来没什么异常。问题只有在我停止看页面、转而看其背后的代码时才显现出来。 ### 阅读 JavaScript 包 与大多数现代单页应用一样，这个门户是一个 Angular 应用，其全部前端逻辑都打包在一个压缩的 JavaScript 文件中。浏览器下载该文件并在本地运行，以渲染应用的所有界面。 该包公开提供，地址为： `` https://cbse.onmark.co.in/cbseevalweb/main.dc17c24606b3b008.js `` 任何人都可以请求它，无论是否登录。于是我对其进行了格式化，然后开始阅读。我看到的内容非常糟糕。 ### 漏洞 1：硬编码的主密码 在前端包中，明文赫然躺着一个**硬编码的主密码**。不是哈希值，也不是令牌引用，而是字面意义上的密码字符串，直接嵌入到了发送给每个访问者浏览器的客户端 JavaScript 中。 比泄露本身更糟糕的是围绕它的逻辑。当这个主密码被输入登录表单时，应用会**自动填写 OTP 字段并完全绕过正常的认证流程**。没有第二因素需要清除，也没有服务器端检查需要满足。输入这个神奇字符串就足够了。 要作为特定考官登录，攻击者只需要： 1. 目标的**用户 ID** 和**学校代码**，这两者都可以公开获得。 2. **主密码**，它就在任何人都可以下载的 JS 文件中。 有了这些，我就能够以考官身份登录（完全绕过 OTP/双因素认证流程）并进入评估仪表板，在那里我可以查看和编辑分数。 ### 漏洞 2：OTP 验证完全在客户端完成 OTP 步骤原来纯粹是演戏。当你触发认证时，**服务器将 OTP 包含在认证响应中发送回来**，浏览器中运行的 JavaScript 在本地将你输入的值与该值进行比较，然后才让你通过。 想想这意味着什么。你本应证明收到的秘密被直接交到了你的浏览器手中，然后浏览器给自己的测试打分。任何查看网络面板的人都可以直接从响应中读取 OTP。而且由于比较发生在客户端代码中，你可以完全跳过表单，直接告诉应用检查已通过。 一个在攻击者机器上运行的安全控制根本就不是控制。 cbse1 ### 漏洞 3：没有路由守卫，整个应用随意进出 即使抛开登录流程不谈，应用的路由也毫无保护。整个 Angular 路由配置**完全没有 `canActivate` 守卫**。像 `/dashboard`、`/profile`、`/evalscriptsview`、`/heallscripts`、`/evaluatordetails` 和 `/verificationdashboard` 这样的路由都可以直接导航访问。 唯一阻止匿名访问者进入内部页面的只是一个默认重定向到 `/login`，但这很容易被击败。通过在浏览器存储中设置一些值，然后直接导航到某个路由，你就可以进入任何你喜欢的页面： `` localStorage.setItem('jwtToken', 'dev-token-12345'); sessionStorage.setItem('role_id', '23'); sessionStorage.setItem('ValType', 'Regular'); sessionStorage.setItem('eval', JSON.stringify({ user_id: 'DEV001', role_id: '23', mobile_no: '9999999999', email: '[email protected]', jwtToken: 'dev-token-12345' })); // 然后导航 window.location.href = '/cbseevalweb/#/dashboard'; `` 将其粘贴到浏览器控制台中，你就会被放到仪表板上，从未对任何东西进行过认证。令牌是假的，用户是捏造的，但应用不在乎。 ### 漏洞 4：无需知道旧密码即可更改任何密码 这就是各个独立漏洞开始组合成完全账户接管的地方。 “更改密码”功能会像你期望的那样收集用户的旧密码。但当我检查它发送的实际请求时，`ChangePassword` API 的有效载荷只包含： `` { "ValuatorID": "...", "pin_NewPassword": "..." } `` `oldpassword` 变量确实存在于组件中，只是**从未被包含在发送给服务器的请求中**。当前密码从未被验证。你在请求体中放入的任何 `ValuatorID`，其密码都会被重置为你选择的任何内容。 孤立的这个问题已经很糟糕了。但结合下一个问题，就变得灾难性了。 ### 漏洞 5：整个 API 存在系统级 IDOR 应用中几乎每个 API 调用都通过从 `sessionStorage["eval"]` 中直接读取 `ValuatorID`/`user_id` 来标识操作用户——就是我上面展示编辑过的那个浏览器存储对象。服务器信任客户端发送的任何 ID，而不是从经过认证的会话中派生。 这使得这成为一个**架构层面的不安全的直接对象引用（IDOR）漏洞**。这不是一个坏掉的端点，而是服务中几乎所有 POST 请求都受影响。更改存储中的 ID，应用就会对该操作充当该用户。 将这些组合起来： - IDOR 使你能够通过修改浏览器中的一个值，**以任何考官的身份** 操作。 - `ChangePassword` API **在未验证旧密码的情况下** 重置密码。 - 因此，你可以将 `ValuatorID` 设置为任何受害者，并将其密码重置为你控制的密码。这就是完全的账户接管，无需任何凭证，无需内部访问权限。 从那里起，攻击者可以合法登录受害者账户、查看分配的答题卡并**修改分数**。在国家级考试这种规模下，其完整性影响不言而喻。 ### 总结 总结一下这些漏洞所允许的行为： - 使用前端中泄露的主密码以任何考官身份登录。 - 完全绕过 OTP，因为验证在浏览器中进行。 - 无需任何认证即可访问任何内部页面。 - 无需知道任何考官的当前密码即可重置其密码。 - 由于系统级 IDOR，可在 API 层面伪装成任何用户，从而**编辑分数、更改考官详情并篡改评估过程**。 这些都不需要复杂的利用手段。最难的部分只是读取一个 JavaScript 文件并在 DevTools 中修改几个值。 ### 负责任披露 在公开写任何内容之前，我向 **CERT-In**（印度计算机应急响应小组）报告了所有这些漏洞。 我的第一封邮件阐述了主密码泄露和客户端 OTP 验证问题。他们回复要求提供更多细节和屏幕录像，于是我发送了完整的演示视频：主密码认证绕过、浏览器控制台登录绕过，以及我后来发现的其他问题，包括缺少路由守卫、密码更改漏洞和系统级 IDOR。 他们的回复是一个模板式的确认： > 尊敬的先生，感谢您向 CERT-In 报告此事件。我们已记录您的投诉/事件，参考编号：CERTIn-XXXXX。我们正在与相关机构采取适当行动。 邮件2 之后，我多次跟进，再也没有收到回复。说实话，有趣的是，我报告的大多数漏洞在很长一段时间内都未修复——如果这些漏洞是我的，我一两个小时就能修好。我们相关部门的无能程度让我震惊。 我暂时没有发布文章，主要是为了给他们一个合理的修复窗口。但这些漏洞一直存在于处理数百万学生考试评分的系统中，而正是这种问题，在负责任地报告之后，应该被公之于众。 ### 教训 如果说有什么教训是给任何构建此类软件的人的，那就是：**永远不能信任客户端。** 这些漏洞每一个都追溯到同一个根本错误：将秘密和安全决策放在运行在用户机器上的代码中。 - 秘密（密码、OTP、任何敏感信息）应放在服务器端，绝不能放在 JavaScript 包中。 - 认证和授权必须在服务器端对每个请求强制执行。 - 用户的身份应来自其经过认证的会话，而不是来自他们可以在 DevTools 中编辑的值。 - 敏感操作（如密码更改）必须验证请求者的权限以及其当前密码。 这些不是高级防御措施。它们是基础。对于一个被赋予维护国家级考试公正性重任的平台，基础的安全措施是我们至少应该期望的。 感谢阅读。