前端校验登录态，等于没校验------一次应急广播终端高危漏洞的发现与报送
本文记录一次已获 CNNVD 收录的高危漏洞（编号：CNNVD-2026-06394172）的发现与报送过程。文中涉及的内网地址、设备编码、账号名均已隐去，也不提供可用于复现的操作步骤，只讨论缺陷构成和防护思路。
一、从一次常规巡检说起
我在基层单位负责网络安全工作，日常巡检里有一项固定内容：对业务终端的 Web 接口做鉴权一致性测试------同一个设备上，逐个接口试一遍"不带凭据能不能访问"。
这次的问题出在一台应急广播终端的调试维护页面上。
这类终端通常有面向运维的调试功能，用来看运行状态、查日志、做一些维护操作。按设计，这类页面只应该给运维人员用，访问前必须经过身份验证。
实测结果是：不登录，直接就能打开。没有跳转，没有 401，页面功能完整可用。
不只是"页面能看见"这么简单。这个调试页面上有命令行输入框，还有一排开发者级的功能按钮------模拟注册、自动播放、工厂测试、煲机测试、U 盘测试、施工结束。这些不是给日常运维用的，是设备出厂调试和产线测试留下的接口。
到这一步，已经是一个明确的未授权访问问题了。但往下看代码，事情比"忘了加鉴权"严重。
图 3：不携带任何凭据，直接取回调试页面的完整 HTML，请求地址已隐去
二、三层缺陷叠在一起
2.1 第一层：调试页面没有访问控制
调试页面本身不做任何身份验证，只要网络能到设备的 80 端口，一个 GET 请求就能把整个页面拿回来。
这属于最常见的缺陷类型，单独出现也不算罕见------很多嵌入式设备的调试接口都是"内网可用所以没做"的状态。但放在应急广播终端上，性质不一样：这类设备部署在县级平台，承担灾害预警和应急指挥的播发任务，通常还和播出、调度系统在同一个内网里。
2.2 第二层：登录判断写在了浏览器里
更关键的问题在这个页面判断"当前用户是否已登录"的方式。
设备的前端代码里，权限判断是这么写的（账号名已隐去）：
javascript
var userName = localStorage.getItem("username");
if (userName === "████████") {
$("a.debug").show();
} else {
$("a.debug").hide();
}这段代码做的事情，严格说不是"校验权限"，而是"根据浏览器里存的一个字符串，决定要不要显示调试菜单"。
localStorage 是用户自己浏览器里的存储，攻击者想写什么就写什么。身份判断的数据源放在客户端，等于把"你是不是管理员"这个问题交给被检查方自己回答。
对比一下两张图就清楚了。下面这张是管理员账号正常登录后的界面------侧边栏里没有"调试"这一项：
图 1：管理员正常登录，侧边栏从"基本信息"到"密码管理"，没有调试入口
而在浏览器控制台里改掉那个本地存储的值、刷新页面之后，同样的账号，侧边栏底部多出了"调试"一项，点进去就是前面那个带命令行和工厂测试的页面：
图 2：只改了本地存储的一个值，调试菜单就出现了------服务端没有做任何二次验证
正确的做法是服务端会话校验：凭据换来的 session/token 由服务端验证，前端只负责携带，不负责判断。这个设备把判断权整个交给了浏览器，服务端对后续请求也没有做二次验证，所以前端那行 if 是唯一一道"门"，而且这道门装在门外。
2.3 第三层：固件里内置了硬编码账号
前端代码里还发现，固件中预置了一个超级管理员的用户名，直接以字符串形式写在 JS 文件里，并且权限判断就是拿用户名字符串做等值比较。
这个账号不随设备交付配置，也改不掉，属于固件级内置------所有同版本固件的设备共享同一个名字。
固件级缺陷意味着：不是某一台设备的配置疏忽，而是同系列设备的共性问题。改配置、换密码都解决不了，只能等厂商出固件更新。
三层叠加的效果：调试页面本来就没有访问控制，登录判断又能被客户端数据绕过，再叠加一个所有设备通用的内置账号------认证体系在调试功能这条路径上实际上是失效的。
三、为什么这类问题值得单独拿出来说
我之前写过一篇从"信任边界"视角看广电嵌入式终端的文章，这次的问题可以放进同一个框架里理解：
设备的信任边界画在了错误的位置。 开发者默认"能打开调试页面的浏览器就是可信的"，于是把身份判断放在了浏览器端。但浏览器是攻击者完全可控的环境------前端代码、本地存储、请求内容，全都可以随意构造。
这不是这个厂商独有的问题。在嵌入式设备上，前端做鉴权、前端存凭据、前端判断权限的写法相当常见，原因是开发人员往往按 Web 应用的思路写嵌入式管理界面，而这两者的威胁模型完全不同：Web 应用的前端代码是公开的但服务端可信；嵌入式设备的前端和服务端都在攻击者触手可及的范围内，前端做的一切"校验"都只能算 UI 提示，不是安全机制。
这里还有一个容易混淆的点：半年前我在同一系列设备上报过另一条漏洞，问题在服务端 API 不校验 token，走的是接口这条路。这次的问题在调试页面和前端权限判断这条路上------两个漏洞在同一个产品里，但根因不同、入口不同，修好一个不影响另一个。做过一次加固不等于这条路径就安全了，这也是排查嵌入式设备时容易漏掉的地方。
四、报送与收录
这个漏洞按程序报送 CNNVD（国家信息安全漏洞库），提交了验证过程、代码分析和影响说明。
CNNVD 完成审核后正式收录，编号 CNNVD-2026-06394172 ，评定等级为高危。
从经验上讲，CNNVD 对这类漏洞的接受度比 CNVD 高------它更看重技术真实性，前端代码审计加上验证过程就足够支撑，不强制要求公网案例。这一点我在之前的流程复盘文章里详细写过，两类平台的证据偏好差异很大，选对渠道能省很多时间。
五、给同类单位的三条建议
如果你的单位也部署着这类"出厂即联网"的行业终端，有三件事值得做：
- 梳理维护接口清单。把设备上所有面向运维的页面、接口、端口列出来，逐个测一遍"不登录能不能访问"。这活不复杂，一个下午能扫完一个网段。
- 把"前端校验"当作"没校验"。审查设备 Web 界面时，打开浏览器开发者工具看一眼：登录判断是服务端返回的状态，还是前端读本地存储下的结论。后者直接按未授权处理。
- 固件内置账号要进台账。交付验收时向厂商索要账号清单，确认哪些是可改的、哪些是内置的。内置账号改不了，就要靠网络隔离来补偿------这类设备不应该出现在任何能被办公网直接访问的位置。
六、小结
这个漏洞没有用到任何高级技术，三个缺陷单独看都不新鲜，叠在一起却让整条认证链失效。嵌入式设备的安全问题大多是这个模式：不是单点多强，而是几处"大家都这么写"的习惯凑到了一起。
漏洞已按程序完成报送与收录，厂商通报由平台负责。作为发现者，能做的是把发现过程和防护思路写出来，让更多部署同类设备的单位少踩这个坑。
作者：刘晓伟，基层融媒体中心网络安全工程师。CSDN 博客长期更新 AI 技术学习、漏洞分析与挖掘、自动化运维方向内容。