誉龙视音频综合管理平台 FindById 存在 SQL 注入漏洞
网络安全启蒙
2026年11月12日 11:45
陕西
去阅读
漏洞类型：SQL 注入（SQL Injection）
危害等级：高危 / 严重
攻击条件：远程、无需身份认证
影响组件：FindById接口
一、漏洞概述
誉龙视音频综合管理平台是一款面向企业级视音频业务的综合管理系统。近日发现其 FindById 接口存在一处 SQL 注入漏洞，且该接口 无需任何身份认证 即可访问。
这意味着：一个未经身份验证的远程攻击者，仅凭一个网络可达的地址，就可以通过构造恶意参数直接操纵平台后端的数据库查询语句。
二、漏洞影响
由于该漏洞无需认证即可触发，攻击者获得的危害面非常广，主要包括：
- 1. 敏感信息泄露
攻击者可以通过 SQL 注入拖库，读取数据库中的各类信息，例如：
- • 管理员后台账号密码（或其哈希值）
- • 站点的用户个人信息（手机号、邮箱、用户名、身份信息等）
- 2. 越权接管平台
获取管理员口令后，攻击者可直接登录管理后台，对平台进行完全控制，篡改配置、删除数据、横向渗透内部业务。 - 3. 写入恶意文件 / 植入木马（高权限场景）
在数据库账户权限较高的情况下（例如具备FILE权限或可通过INTO OUTFILE/LOAD_FILE等），攻击者可以：
- • 向服务器 Web 目录写入 WebShell（木马）
- • 进一步获取服务器系统权限，实现 远程代码执行（RCE）
- • 将受控主机作为跳板，向内网横向扩散
- 4. 数据篡改与破坏
注入点支持写入型语句时，攻击者可任意修改、删除业务数据，甚至清空数据库。
三、影响版本
誉龙视音频综合管理平台（具体受影响版本请以厂商官方通告为准，建议核对平台版本信息）。
四、检测 / 测绘
1. FOFA 测绘语法
body=\"PView 视音频管理平台\" && country=\"CN\"
可用于快速测绘全网暴露的受影响资产。
2. 资产自查
- • 梳理内部及托管的所有平台实例，确认是否对外直接暴露了
FindById接口。 - • 通过日志审计，检查是否存在针对该接口的异常参数请求（如带有
'、union、sleep等特征的访问记录）。
五、漏洞成因（技术分析）
SQL 注入的根本成因，通常在于 后端将用户可控的输入直接拼接进 SQL 语句，而没有做参数化 / 预编译处理。以 FindById 为例，典型的危险写法类似：
// 危险：直接拼接用户输入
String sql = \"SELECT * FROM device WHERE id = '\" + id + \"'\";
当 id 参数被传入 1 or 1=1、1' union select ... -- 这类内容时，原始 SQL 语义被恶意改写，从而造成注入。
修复的核心原则：绝不将原始输入直接拼接到 SQL 语句中。
五（附）、PoC 复现
该接口可通过 updatexml() 触发 报错注入（Error-based SQL Injection）。updatexml() 在 XML 路径表达式非法时会抛出错误，并回显拼接后的内容，攻击者可借此把数据库中的信息带到响应中。
下面用一个无害探针（md5(123456)）验证注入点是否存在——响应中若回显出 ~01ba4719c80b6fe911b091a7c05124b6~（即 ~ + md5 + ~），即可确认漏洞成立：
id=1+and+updatexml(1,concat(0x7e,md5(123456),0x7e),1)--
原理拆解：
- •
0x7e：即字符~，用作分隔符，便于在错误信息中快速定位回显的注入结果。 - •
md5(123456)：无害验证探针，其值为01ba4719c80b6fe911b091a7c05124b6，用于确认注入点可执行并回显，而不真正拖取敏感数据。 - •
concat(...)：把分隔符与目标表达式拼接进updatexml的路径参数。 - •
updatexml(1, ..., 1)：第二个参数本应是合法的 XPath，此处故意构造非法表达式触发报错，从而把concat的内容带进错误回显。 - •
--：注释掉后续 SQL，避免语法冲突。
升级利用（示意，仅用于授权测试）：
验证注入点后，攻击者可将 md5(123456) 替换为真实查询，例如读取版本、当前库名、表名乃至管理员口令：
id=1+and+updatexml(1,concat(0x7e,version(),0x7e),1)-- # 数据库版本
id=1+and+updatexml(1,concat(0x7e,database(),0x7e),1)-- # 当前库名
id=1+and+updatexml(1,concat(0x7e,user(),0x7e),1)-- # 当前数据库用户
说明：以上 payload 仅供在 已获授权 的目标系统上复现与验证。请勿在未授权系统上使用。
六、修复建议
- 1. 使用预编译 / 参数化查询（首选）
使用PreparedStatement等占位符方式，让数据库对参数做类型隔离，从根本上杜绝注入：
// 安全：参数化查询
PreparedStatement ps = conn.prepareStatement(\"SELECT * FROM device WHERE id = ?\");
ps.setInt(1, id);
2. 2. 输入校验与类型约束
FindById 的 id 本质是数字 / 主键类型，应对输入做严格的类型与格式校验（如正则限定为数字），非法输入直接拒绝。
3. 3. 最小权限原则
为平台数据库账户分配最小必要权限，移除 FILE、INSERT、DROP 等高危权限，避免在注入成功时进一步写入文件或破坏数据。
4. 4. 认证与访问控制
FindById 这类查询接口 应当纳入身份认证与鉴权体系，不应裸露在公网无认证访问。
5. 5. WAF / 数据库审计（纵深防御）
在网关层部署 WAF 规则拦截典型注入特征，同时开启数据库审计与告警，作为兜底防线。
6. 6. 升级到官方修复版本
关注并应用厂商发布的官方补丁 / 修复版本。
七、总结
本次漏洞的核心风险点在于：无认证 + SQL 注入 的组合，使得攻击门槛极低、危害极大。攻击者无需账号密码即可直接触碰数据库，进而可能导致信息泄露、平台失陷乃至服务器沦陷。
建议相关用户：
- • 尽快自查受影响资产；
- • 优先采用参数化查询加固相关接口；
- • 收敛数据库账户权限、补齐接口鉴权；
- • 关注并应用官方修复版本。
> 免责声明：本文仅用于安全研究与防御目的。请遵守《网络安全法》及相关法规，未经授权不得对非目标系统进行测试或攻击。技术细节请以厂商官方通告为准。
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论