对比织梦 CMS 为什么建议优先修复 pbootCMS 的 SQL 注入

如果你的站点正在使用 PbootCMS 且对外提供服务，建议优先于织梦 CMS 处理其 SQL 注入问题。虽然织梦 CMS 历史漏洞较多，但 PbootCMS 的模板标签解析机制导致的注入点更隐蔽，且由于织梦已停止官方维护，其风险边界相对固定，而 PbootCMS 作为活跃框架，新业务场景下的模板滥用风险更高。

先说结论：优先修复 PbootCMS 是因为其漏洞利用链更隐蔽，且官方补丁可能存在滞后或需手动加固。

先判断：确认是否使用了存在风险的模板标签功能，而非仅看版本号。
优先做：对 TagController.php 等核心文件进行代码层过滤或部署针对性 WAF 规则。
再验证：通过日志监控和安全扫描确认注入尝试是否被拦截。

织梦与 PbootCMS 注入风险对比

很多站长纠结于先修哪个 CMS，以下是两者在 SQL 注入风险上的核心差异，帮助理解为何优先处理 PbootCMS：

注入载体过滤难点修复优先级

对比维度	织梦 CMS (DedeCMS)	PbootCMS
维护状态	已停止官方维护，漏洞固定	活跃维护，但新功能可能引入新风险
传统 URL 参数、表单提交	模板标签解析（如 {pboot:list}）
全局变量过滤较成熟	模板引擎二次解析易绕过全局过滤
中（边界清晰）	高（逻辑隐蔽，易被自动化扫描忽略）

核心代码修复方案

由于该漏洞涉及代码逻辑而非单纯配置，无法通过一条命令修复。以下是针对 TagController.php 中常见漏洞模式的修复 Diff 示例。

1. 定位文件

检查网站目录下 apps/home/controller/TagController.php 是否存在。

2. 代码修复对比

找到处理 filter 参数的逻辑，参考以下修改方案：

// 【修复前】存在风险的代码片段
public function index() {
    $filter = input('filter'); // 直接获取用户输入
    if ($filter) {
        // 风险：直接拼接到 SQL 条件中
        $where[] = $filter; 
    }
    $data = $this->orm->table('ay_content')->where($where)->find();
}

// 【修复后】建议的安全代码片段
public function index() {
    $filter = input('filter'); 
    if ($filter) {
        // 修复：强制白名单校验或参数化
        // 方案 A：仅允许特定字段排序或简单条件
        if (!preg_match('/^[a-zA-Z0-9_,=]+$/', $filter)) {
            abort(403, 'Invalid filter parameter');
        }
        // 方案 B：使用框架提供的安全查询构造器
        $where[] = ['field', '=', $filter]; 
    }
    $data = $this->orm->table('ay_content')->where($where)->find();
}

注意：修改核心文件前务必备份原文件，并在测试环境验证业务功能是否正常，避免误杀正常请求。

WAF 拦截配置示例

如果无法立即修改代码，可在 Web 服务器层部署临时拦截规则。以下规则旨在拦截带有明显 SQL 注入特征的 filter 参数请求。

Nginx 配置示例：

server {
    listen 80;
    server_name example.com;

    location / {
        # 拦截 filter 参数中包含 SQL 关键词的请求
        if ($args ~* "filter=.*(union|select|insert|update|delete|drop|sleep|benchmark)") {
            return 403;
        }
        
        # 拦截包含大括号模板标签的请求（视业务情况开启）
        if ($args ~* "\{pboot:") {
            return 403;
        }

        try_files $uri $uri/ /index.php?$query_string;
    }
}

Apache 配置示例 (.htaccess)：

RewriteEngine On
# 拦截包含 SQL 关键词的 filter 参数
RewriteCond %{QUERY_STRING} filter=.*(union|select|insert|update|delete|drop|sleep|benchmark) [NC]
RewriteRule .* - [F,L]

验证与排查

修复完成后，请按以下步骤验证是否生效：

查看访问日志：搜索包含 union select 或 {pboot:list} 关键词的请求，确认是否有返回 200 状态码的成功访问。修复后应返回 403 或 500。
使用扫描工具：使用合法的漏洞扫描工具对目标站点进行 SQL 注入测试，观察是否还能报出数据库语法错误。
监控数据库日志：开启 MySQL 慢查询或通用日志，观察是否有异常的 SQL 语句执行记录。

常见坑

盲目升级：仅升级框架版本不一定能彻底修复，因为部分漏洞源于模板解析逻辑，需人工验证所有 M()->find() 或 M()->where() 调用是否都改用了参数占位符。
忽略自定义模板：开发者自定义的模板标签可能绕过官方过滤逻辑，需对所有自定义标签进行审计。
过滤不全：仅过滤 $_GET 是不够的，$_POST 和 $_COOKIE 同样可能成为注入载体，需在入口层做白名单式校验。
业务中断风险：WAF 规则过于严格可能拦截正常业务请求（如某些搜索功能），建议先开启日志记录模式观察一段时间后再启用拦截。

参考来源

PbootCMS 官方安全公告与更新日志
CNVD 关于 CMS 系统模板注入漏洞的分析报告
OWASP Top 10 SQL Injection Prevention Cheat Sheet
常见 CMS 系统安全加固实践指南