CMS历史漏洞复现环境搭建，测试防护策略

想搞懂一个CMS历史漏洞到底怎么被利用、又该怎么防，最直接的办法就是在本地搭一套隔离的复现环境。
本文用Docker在Linux上搭建一套可随时销毁的CMS漏洞测试环境，带你走完从拉取镜像、触发漏洞到配置防护策略验证的完整流程。
整个过程不碰生产服务器，零基础也能跟着做，最终你会得到一个能反复练习的漏洞靶场，并清楚哪些防护手段真正有效。

复现环境选型与前置条件

复现漏洞最怕影响真实业务，所以第一步不是装CMS，而是想清楚隔离方案。
推荐用Docker，因为容器删掉就干净了，不会污染宿主机。

准备条件如下：

• 一台Linux测试机，Ubuntu 20.04或CentOS 7以上均可，内存建议2GB以上
• 已安装Docker和Docker Compose，用docker --version确认可用
• 测试机不要放对外业务，最好用内网IP或仅本机访问
• 提前确认你要复现的CMS漏洞对应的版本，不同版本漏洞点可能不同

需要特别提醒：漏洞复现必须限定在授权或自建环境内，对外网真实站点做测试属于违规行为。
本文所有操作都假设你在自己的测试机上进行。

用Docker搭建CMS漏洞靶场

这里以常见的PHP类CMS为例，思路对大多数CMS通用。
我们创建一个独立目录，把数据库和Web服务编排在一起。

先建工作目录：

mkdir -p /opt/cms-lab && cd /opt/cms-lab

编写docker-compose.yml，把Web和MySQL分开，方便观察漏洞触发时数据库的变化：

version: '3'
services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: lab123456
      MYSQL_DATABASE: cms
    volumes:
      - ./dbdata:/var/lib/mysql
  web:
    image: php:7.2-apache
    ports:
      - "8080:80"
    volumes:
      - ./webroot:/var/www/html
    depends_on:
      - db

启动服务：

docker-compose up -d

用docker-compose ps确认两个容器都是Up状态后，把对应版本CMS源码解压到./webroot，浏览器访问http://测试机IP:8080完成安装。
安装时数据库地址填db（容器名），不是localhost，这是新手最容易卡住的地方。

触发漏洞并观察现象

环境装好后，不要急着打payload，先确认漏洞存在。
以SQL注入类漏洞为例，找到CMS中未过滤参数的入口，比如某个id=1的查询接口。

手动在参数后加一个单引号，观察页面是否报数据库错误：

http://测试机IP:8080/xxx.php?id=1'

如果出现SQL语法错误回显，说明参数没做过滤，漏洞很可能存在。
接着用sqlmap这类工具做验证时，务必只指向自己的测试IP：

sqlmap -u "http://127.0.0.1:8080/xxx.php?id=1" --batch

判断漏洞复现成功的标准：能稳定读到数据库信息，或能复现出越权、文件包含等对应危害，而不是只看到一个报错页。
复现记录要保存请求和响应，方便后续对比防护效果。

防护策略配置与验证对比

复现的目的是验证防护，所以这一步才是重点。
常见防护分几层，建议逐层加、逐层测。

输入过滤层：在CMS代码或框架入口对参数做类型校验和转义，比如PHP里用预处理语句替代拼接SQL。
改完后重放刚才的payload，如果不再报错、也读不到数据，说明这层生效。

WAF层：在Web前面加一层反向代理，用Nginx配合基础规则拦截明显攻击特征。
例如在nginx.conf中限制可疑参数：

if ($args ~* "(union|select|sleep|benchmark)") {
    return 403;
}

改完执行nginx -s reload，再次发送payload，预期返回403而不是正常页面。

权限层：把数据库账户从root换成只有必要权限的普通用户，即使注入成功，危害也被限制。
改完在CMS配置里更新数据库账号，重启容器验证业务正常。

验证方法：每加一层防护，就把之前的payload重放一次，记录返回码和响应内容。
如果从“能读到数据”变成“403”或“报错但无数据”，说明防护有效。

常见坑与收尾建议

几个容易踩的坑提前说清楚：容器里PHP默认没装mysqli扩展，CMS可能连不上数据库，需要进容器用docker-php-ext-install mysqli补上；
MySQL 5.7和8.0的认证方式不同，老CMS可能连不上8.0，这也是选5.7的原因；
测试完记得docker-compose down -v清掉数据卷，避免残留环境被误用。

核心结论：漏洞复现环境必须隔离、可销毁；
防护策略要分层验证，单靠一层往往不够；
每加一层防护都要用同一payload重放对比，才能确认是否真的生效。

如果你正在做CMS历史漏洞复现环境搭建并测试防护策略，建议先把环境跑通、漏洞复现成功，再逐层加防护并记录对比结果。
遇到业务异常时，优先回看数据库连接和容器扩展这两处高频问题。