帝国cms纯后台页面需要防 SQL 注入吗

作者：凡帝网分类：帝国CMS教程发布时间：2026-07-24 浏览量：41 次

后台页面已经过了登录验证和管理员权限检查，能操作的都是管理员。管理员真想搞破坏，直接在后台执行 SQL 语句就行了，不用费劲注入。那为什么还要在后台代码里做层层 SQL 注入防护？

1. 防的不是管理员，是 CSRF + SQL 注入的组合拳

先看清两个东西各自解决什么问题：

CSRF（跨站请求伪造）——让已登录的管理员在不知情的情况下发出一个请求
SQL 注入——在参数里夹带 SQL 代码，让数据库执行预期之外的操作

单独看，每个都有限制条件。但组合起来就麻烦了。

GET 型 CSRF + 未过滤参数

假设后台有个删除信息的功能：

// 某个边缘功能，filename 从 GET 来，没过滤直接拼 SQL
$filename = $_GET['filename'];
$empire->query("DELETE FROM {$dbtbpre}ecms_article WHERE filename='{$filename}'");

攻击者构造一个页面：

<!-- 攻击者的网站/论坛签名/邮件里 -->
<img src="https://cms.example.com/eadmin/admin/ecmsinfo.php
     ?enews=DelNews&filename=x' OR '1'='1" />

管理员登录后台后，在另一个标签页里随便打开个网页，这个 img 标签就触发了。浏览器自动带上后台 Cookie，请求发到 ecmsinfo.php——服务器一看 Cookie 有效、Session 有效，这是管理员的请求，于是执行。

结果是：filename='x' OR '1'='1' → 全表删除。

这里的关键不是 CSRF 本身有多可怕，而是 CSRF 让 SQL 注入突破了"需要管理员权限"这个限制条件。

POST 型 CSRF 更隐蔽

<form id="f" action="https://cms.example.com/eadmin/admin/ecmsinfo.php" method="POST">
  <input name="enews" value="AddNews" />
  <input name="title" value="正常标题" />
  <input name="newstext" value="'; DROP TABLE phome_ecms_article_doc_data; --" />
  <input name="classid" value="1" />
  <input name="ecmsfrom" value="9" />
</form>
<script>document.getElementById('f').submit();</script>

这个表单隐藏在一个看起来无害的页面里，管理员打开页面，表单自动提交。如果 formhash 校验有漏洞，或者压根没校验，那一条带注入内容的文章就写进去了。

历史是怎么被打穿的

攻击者找到后台某个 GET 参数的 SQL 注入漏洞
  → 但漏洞需要管理员权限才能触发
  → 于是配合 CSRF：在公开页面里埋一个 img 标签
  → 骗管理员访问该页面
  → 管理员浏览器自动发 GET 请求到后台
  → Cookie 生效 → 服务器认为是管理员操作
  → 注入成功 → 数据泄露/删表

2010 年代大量 CMS 被打穿就是这个套路。漏洞通常不在 AddNews 这种核心函数里（核心函数反而写得谨慎），而是在一些导出、统计、日志等边缘路径。

一句话说清这层关系

CSRF 解决"怎么让请求以管理员身份发出去"，SQL 注入解决"一个请求能造成多大破坏"。 没了 CSRF，攻击者构造不了合法请求。没了 SQL 注入，攻击者构造了请求也只能做界面允许的操作，破坏有限。两者一结合，攻击者就能让管理员帮他执行任意 SQL。

2. 代码复用——前台后台用的是同一套函数

这是工程上的直接原因。数据处理函数通常前后台共用：

// 后台发布
AddNews($_POST, $logininid, $loginin);

// 前台会员投稿——本质上走到同一个数据处理函数

如果后台的数据处理函数不做过滤，那它就不能在需要过滤的前台路径上用。帝国的选择是：数据处理层统一过滤，不管调用者是谁。 这样做还有一个好处——新增入口时过滤自动继承，不会漏掉。

3. 纵深防御——不信任上游

安全设计有个基本原则：每层都假设上一层已经被绕过。

HTTP请求 → 身份验证 → 权限检查 → 参数处理 → SQL查询
                         ↑
                    假设这一层有 BUG

is_login() 历史上出现过 Session 伪造漏洞
CheckLevel() 配置错了可能越权
管理员账号被猜出来
管理员把密码贴在显示器上

SQL 注入过滤是最后一道防线，保证上面所有防线都失守了，至少 ' OR '1'='1 不会被执行。

4. 操作容错——防手滑

管理员自己操作也能触发问题：

// 管理员在标题里输入：It's a test
// 没有 addslashes：
INSERT INTO ... VALUES('It's a test')
//                    ^^^^^^^^ 语法错误
// 有 addslashes：
INSERT INTO ... VALUES('It\'s a test')

没有过滤，管理员自己输个单引号就能让页面报错甚至写不进数据。addslashes 在这层意义上既是安全措施，也是数据完整性保障。

总结

理由	评价	实质
防外部攻击者直接注入	不需要	攻击者根本进不到这个函数
防 CSRF 组合利用	需要	CSRF 让 SQL 注入突破权限限制
代码复用去前台	需要	同一套函数，没法割裂
防认证层被绕过	需要	纵深防御
防手滑	顺便的事	`addslashes` 零成本