漏洞背景与概述

织梦作为一款广泛使用的内容管理系统，其平安性一直备受关注。近年来 针对织梦的平安研究逐渐织梦中common.inc.php文件因SESSION变量覆盖导致SQL注入的技术细节、攻击原理及防护策略。

---

什么是SESSION变量覆盖？

在PHP应用中，$_SESSION数组用于存储用户会话数据，通常由服务器维护并保护。只是 在特定配置和代码设计不严谨的情况下攻击者可以通过构造特殊请求，将恶意数据注入到$_SESSION数组中，从而实现对会话数据的覆盖。这种行为被称为SESSION变量覆盖。

产生原因

• session.auto_start = 1： 当PHP配置开启自动启动Session时 每次请求自动调用 session_start这会使得全局作用域内存在一个默认的 $_SESSION 数组。
• 不平安的变量注册机制： 某些老版本织梦采用了类似“魔术引用”或不严谨的全局变量导入策略，比如用 extract 或直接将输入数据注册为全局变量。
• 缺乏对关键前缀变量名检测和过滤： 允许用户提交带有敏感前缀的参数覆盖关键系统变量，包括SESSION。

这些因素结合后 就可能使攻击者构造请求时利用POST/GET/COOKIE参数强行覆盖$_SESSION中的部分数据。

---

漏洞形成路径解析

1. common.inc.php中的核心代码分析

以织梦系统中的 /include/common.inc.php 文件为例，该文件负责初始化环境和处理请求数据。关键代码如下：

php foreach as $_request) { foreach { if> 0 && preg_match#', $_k) ) { exit; } ${$_k} = _RunMagicQuotes; } }

该段代码尝试阻止用户传入某些关键前缀开头的参数，如 cfg_, GLOBALS, _GET, _POST, _COOKIE。但是明显缺少了对 _SESSION 前缀的过滤。这就导致：

• 攻击者可以传递名为 _SESSION 的参数，从而成功注入和覆盖原本存储在服务端 $_SESSION 的值。

2. advancedsearch.php中的SQL查询风险点

在织梦 /plus/advancedsearch.php 中， 有类似以下代码片段：

php $sqlhash = $_SESSION; $query = "SELECT * FROM #@__archives WHERE some_column='{$sqlhash}'";

这里直接从Session读取 $sqlhash 并插入到SQL查询语句中，没有任何过滤或预处理。如果攻击者能够通过请求参数覆盖该Session值， 则可实现任意SQL语句施行，即发生典型SQL注入漏洞。

---

漏洞利用条件详解

1. session.auto_start必须开启

   自动启动Session机制使得每个请求均包含初始化好的 $_SESSION 数组，为攻击提供基础条件。

2. 系统允许通过外部输入参数改变全局或超全局数组

   未禁用或未正确限制用户传递的数据对内部Session数组产生影响。

3. 缺乏有效过滤机制

   无法阻止带有 SESSION 前缀的数据进入运行环境。

4. 业务逻辑没有做好输入校验和转义

   导致Session内存储的数据可被恶意篡改进而影响数据库查询。

---

实际案例演示

假设目标站点未做修补， 并且服务器PHP配置启用了session.auto_start，我们可以模拟如下攻击流程：

攻击步骤

1. 构造HTTP请求，将含有特殊键名的参数注入：

POST /plus/advancedsearch.php HTTP/1.1 Host: target.com Content-Type: application/x-www-form-urlencoded

_SESSION=1' OR '1'='1

2. 服务端自动将该参数转换为：

php $_SESSION = "1' OR '1'='1";

3. 查询语句变为：

sql SELECT * FROM archives WHERE some_column='1' OR '1'='1'

4. 导致无条件返回数据库所有记录，实现SQL注入。

---

修复方案详解与源码修改建议

云盾团队修复策略介绍

云盾团队针对上述漏洞提出通用防御思路：在输入注册入口统一禁止来自外部的数据对重要超全局数组包括 SESSION 的传递，实现白名单或者黑名单管理防止敏感KEY被覆写。

修复步骤详解

第一步：修改过滤规则， 加入对 SESSION 的限制

在 /include/common.inc.php 文件内找到以下字符串：

php if> 0 && preg_match#', $svar) )

替换成：

这样就能禁止带有 _SESSION 前缀的数据被接收和注册成全局变量，从源头杜绝了这类Session变量被外部篡改的问题。

第二步：增强循环遍历逻辑加入严格拦截判断

将原始处理输入循环修改为如下形式：

这样能有效阻断凶险键名导致的不当赋值行为，也间接保护了涉及到Session相关操作的数据完整性。

---

防护建议与最佳实践

不要开启 session.auto_start 参数

手动控制 session 启动时机，更加灵活且平安。一边避免自动创建 Session 导致不可控风险。

禁止外部传参直接映射到重要超全局数组

避免使用诸如 extract 等函数批量导入用户提交数据， 更不要让其直接影响 $_SESSION、$GLOBALS 等敏感数据结构。

使用预处理语句

绝不能直接拼接来自用户或者未验证来源的数据至 SQL 查询语句， 应使用 PDO 或 MySQLi 的预处理功能保证查询平安性，有效防范 SQL 注入风险。

定期更新系统补丁

关注官方及第三方平安团队发布的信息，并及时更新对应补丁版本。比方说本文提到云盾团队发布过对应修复包，应第一时间部署以降低风险暴露窗口期。

---

技术前瞻：为何这种类型漏洞依然频发？

• 历史遗留问题多 老旧系统习惯使用魔术引用及register_globals等过时功能， 这些功能已知存在大量平安隐患，但依然在部分站点沿用甚至开启。

• 开发人员平安意识不足 许多开发者依赖框架默认设置， 对底层环境配置了解有限，对超全局数组操作缺乏严格把控。

• 复杂项目维护困难 大型CMS集成众多插件、 第三方模块，不同模块之间可能存在相互干扰，引发隐蔽性较强的新型漏洞。

所以呢，加强开发培训、平安审计及采用现代化编码规范，是长期解决此类问题的重要方向。

---

织梦Dedecms因其架构设计与历史遗留特性，使得通过Session变量覆盖实现SQL注入成为现实威胁。具体表现在于常见文件 common.inc.php 中对敏感超全局数组监测不足，以及在业务逻辑层面直接信任未经处理的Session数据。本文详细分析了这一漏洞产生机理，并给出基于云盾团队提供修补方案的实战性修改建议。还有啊， 还强调了合理配置PHP环境、强化代码编写规范以及采用现代数据库访问方式的重要性，以提升整体网站平安水平，避免类似风险反复出现。

---

以上内容既涵盖了理论剖析， 也兼顾实战案例，一边结合当前最新技术态势，为相关开发运维人员提供全面深入参考，是保护织梦系统免遭此类严重威胁不可或缺的一环。

---