LMXCMS 1.4 SQL注入漏洞实战审计：从原理到修复

原创

于 2026-06-24 09:53:11 发布 · 220 阅读

1. 项目概述：从一次实战审计看LMXCMS 1.4的注入风险

最近在整理一些老版本CMS的审计案例，LMXCMS 1.4这个版本进入了我的视野。它虽然不算特别主流，但在一些特定场景下仍有使用，其代码结构清晰，对于学习代码审计和漏洞挖掘来说是个不错的“标本”。这次我们聚焦的核心，是它存在的前后台SQL注入漏洞。很多朋友一听到“注入”就觉得是老生常谈，但恰恰是这些“老问题”，在缺乏维护的旧系统中最为致命。通过复现这个漏洞，我们不仅能掌握一个具体的攻击链，更能深入理解在代码审计中，如何定位过滤不严的输入点、如何追踪数据流、以及如何构造有效的Payload。整个过程，我会带你从环境搭建、代码分析，一直走到漏洞利用和修复建议，手把手还原一次完整的审计实战。

2. 环境搭建与代码定位

2.1 靶场环境快速部署

要进行漏洞复现，首先需要一个可操作的环境。我推荐使用Docker来快速搭建，这能保证环境的纯净和可复现性。你可以从一些开源漏洞靶场仓库或者历史版本存档站点找到LMXCMS 1.4的源码。拿到源码后，我们本地搭建一个集成了PHP和MySQL的Web环境。

我习惯用 docker-compose 来管理，配置文件大致如下：

version: '3'
services:
  web:
    image: php:5.6-apache
    volumes:
      - ./lmxcms1.4:/var/www/html
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: lmx_cms
    volumes:
      - mysql_data:/var/lib/mysql
volumes:
  mysql_data:

这里选择PHP 5.6和MySQL 5.7是为了匹配LMXCMS 1.4发布时期的典型运行环境，避免因版本过高导致语法兼容性问题。启动服务后，访问 http://localhost:8080/install 按照向导完成安装。安装过程中，注意记录下数据库的连接配置，后续审计时会用到。

注意：请务必在隔离的虚拟机或本地网络中进行此实验，切勿对公网或未经授权的系统进行测试。所有操作仅用于安全研究与学习。

2.2 核心代码结构与审计入口点分析

安装完成后，我们浏览一下LMXCMS 1.4的代码目录结构。其核心逻辑通常集中在 /admin/ （后台）、 /include/ （公共函数和类库）、以及各功能模块目录下。对于SQL注入漏洞，我们的审计焦点自然放在所有与数据库交互的地方，特别是那些接收外部参数并直接拼接到SQL语句中的位置。

一个高效的策略是全局搜索关键词，如 $_GET 、 $_POST 、 $_REQUEST ，并查看其是否被传入到 mysql_query() 、 mysqli_query() 或框架的查询方法中。在LMXCMS中，可能会有一个公共的数据库操作类或函数，我们需要找到它，并检查其是否对输入进行了充分的过滤。

3. 漏洞原理深度解析与定位

3.1 前台注入漏洞挖掘

通过全局搜索和代码回溯，我首先在用户交互较为频繁的前台模块发现了疑点。例如，在文章内容展示或搜索功能中，程序往往会根据URL参数（如文章ID id 、分类 classid ）来查询数据库。关键代码可能如下所示：

// 伪代码示例，可能存在问题的原始写法
$id = $_GET['id'];
$sql = "SELECT * FROM lmx_article WHERE id=$id";
$result = mysql_query($sql);

这里， $id 变量直接从 $_GET 获取，未经任何过滤就直接拼接进SQL语句。如果 $id 是一个数字，理论上应该是安全的，但PHP的弱类型特性可能带来风险。更重要的是，我们需要确认程序是否在所有类似的地方都做了类型强制转换或转义。

实际审计中，我发现在 /include/ 下的某个公共函数文件里，存在一个用于执行SQL的快捷函数，但它内部仅仅使用了 addslashes() 进行转义。 addslashes() 在特定字符集（如GBK）下可能存在宽字节注入绕过的问题，并且它无法防御数字型注入。这就是一个典型的漏洞根源。