大汉统一内容管理系统 commonlist.jsp queid 参数 SQL 注入漏洞复现

Wayyt 2小时前

大汉统一内容管理系统 commonlist.jsp queid 参数 SQL 注入漏洞复现

0x00 漏洞概述

大汉版通（HanWeb/JCMS）统一内容管理系统是国内政府与事业单位网站群中广泛使用的一套内容管理产品。其投票模块下的 commonlist.jsp 页面在处理 queid 参数时未做任何过滤与预编译处理，直接将参数值拼接进 Oracle 数据库查询语句，导致数字型 SQL 注入漏洞。攻击者无需登录，仅凭一个前台 GET 请求即可通过 UNION 联合查询操纵数据库执行任意查询，进而读取或篡改站点数据，最终可能造成网页被篡改、数据被篡改等后果。本次复现即针对这一注入点展开。

0x01 影响范围

产品：大汉统一内容管理系统（大汉版通 HanWeb/JCMS）；
注入点：投票模块 commonlist.jsp 页面的 queid 参数；
利用前提：目标站点投票模块页面可被前台匿名访问；
受影响版本：公开渠道未给出明确版本区间，无对应 CVE/CNVD 编号，此处不做臆断，建议按部署自查。

资产识别方面，该产品站点普遍带有明显指纹：页面底部出现 Produced By 大汉网络字样、页面源码中存在指向 hanweb.com 的隐藏链接、me ta 标签的 Generator 或 Author 字段标注大汉版通/大汉网络、静态资源路径包含 /jcms_files/jcms 等，均可用于定位目标。

0x02 漏洞分析

commonlist.jsp 位于 /module/voting/ 目录下，是投票模块渲染投票项列表的页面。从注入 payload 的形态可以反推出服务端 SQL 的拼接结构：请求中 queid 的值以 -12) 开头，说明参数被直接嵌入了一段带有括号的子查询中，攻击者用一个右括号闭合原始语法后再接 UNION ALL；payload 共构造了 14 个查询列（第 8 列为注入列，其余用 NULL 占位），说明原始查询的返回列数为 14。

两个细节值得注意。其一，字符串构造完全依赖 chr() 函数逐字符拼接（chr(115)||chr(99)||...），这样整个 URL 中不出现任何引号，可以绕过基于引号过滤的简单防护； FROM DUAL 则是 Oracle 语法的标志性特征，据此可判定后端数据库为 Oracle。其二，URL 行尾的 -- 注释符将其后拼接进 SQL 的残余内容整体吞掉，保证语法闭合；同一 URL 中后面的 m、inlay、answer 等参数在 HTTP 层面仍然存在并被服务端正常接收，只是其进入 SQL 的部分已被注释失效。

回显路径上，判定条件要求响应体同时出现 document.write(" 与注入串内容，说明注入列的值会随页面渲染写回前端脚本输出。研究者据此可以利用第 8 列携带任意探测串，通过页面回显确认注入成立，再逐步替换该列读取库内数据。

0x03 利用链与请求包

利用链为单请求：向投票模块列表页提交带 UNION 注入的 queid，通过响应内容判断注入是否成立。整个过程无需认证、无需 Cookie。

请求包如下（目标为示意地址）：

GET /module/voting/commonlist.jsp?classid=0&queid=-12) UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,chr(115)||chr(99)||chr(97)||chr(110)||chr(110)||chr(101)||chr(114)||chr(58)||chr(105)||chr(59)||chr(102)||chr(105)||chr(110)||chr(100),NULL,NULL,NULL,NULL,NULL,NULL FROM DUAL-- &m=yes&inlay=yes&answer= HTTP/1.1
Host: 10.0.0.10

其中 chr 序列解码后为字符串 scanner:i;find（115=s、99=c、97=a、110=n、110=n、101=e、114=r、58=:、105=i、59=;、102=f、105=i、110=n、100=d），作为第 8 列的探测值。注入成功的判定条件需同时满足：