苹果CMS作为国内常见的影视建站系统，其开源版本因历史代码遗留问题，曾多次曝出严重的SQL注入、远程代码执行以及任意文件删除漏洞。这些漏洞往往集中在搜索模块、评论接口与模板解析逻辑中，一旦被利用，攻击者不仅能窃取全站数据，还可通过写入恶意脚本控制服务器，或直接删除关键锁文件使站点重装。本文将从漏洞成因、SQL注入与代码执行修复、任意文件删除防护三个层面，给出可落地的修补方案。
漏洞成因与攻击链路分析
苹果CMS旧版在处理用户输入时，大量使用字符串拼接方式构造SQL语句。例如在搜索功能中，用户提交的keyword参数未经严格转义便直接进入查询条件，攻击者可构造keyword=1' union select ...这类载荷，改变原查询逻辑并读出管理员账号。此类问题根源在于开发者混淆了数据与指令边界，把用户数据当成了SQL语法的一部分。
在拿到数据库权限后，攻击者通常会借助苹果CMS的模板解析机制实现远程代码执行。系统允许在模板中使用特定标签动态包含文件或执行PHP代码，若后台鉴权被绕过或使用了弱口令，恶意模板被写入后，前台访问即触发WebShell。与此同时，任意文件删除漏洞多出现在缓存清理或附件管理接口，这些接口接收用户提交的path参数后未校验目录归属，直接调用unlink函数，使得install.lock等文件可被删除，站点面临重装风险。
从攻击链路看，SQL注入是入口，远程代码执行是落脚点，任意文件删除则是破坏可用性的手段。三者相互独立又常被组合利用，因此修复时必须同步处理，仅修补单点无法消除整体威胁。理解这一链条，有助于我们在代码审计时优先关注参数入口与文件系统操作点。
SQL注入与远程代码执行修复办法
修复SQL注入最直接有效的方式是弃用字符串拼接，全面改用PDO预处理。以下示例展示如何将危险查询改写为安全形式。原代码常写为$sql = "select * from mac_art where art_name like '%".$_GET['name']."%'";，攻击者只需闭合引号即可注入。改用预处理后，参数与语句分离，数据库驱动会自动转义。
<?php
$pdo = new PDO('mysql:host=localhost;dbname=applecms', 'user', 'pass');
$name = isset($_GET['name']) ? $_GET['name'] : '';
// 使用命名占位符，彻底隔离用户输入与SQL指令
$stmt = $pdo->prepare('select * from mac_art where art_name like :name');
$stmt->execute([':name' => '%' . $name . '%']);
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
?>
对于远程代码执行，必须限制模板引擎的可执行标签。苹果CMS的模板解析若支持{php}这类标签，应在配置中关闭，或重写解析函数仅允许安全变量输出。如下代码展示如何在解析前过滤危险标签，防止用户提交的内容被当作PHP执行。
<?php
function safe_parse($tpl) {
// 禁止模板中出现php执行标签
if (preg_match('/{php}/i', $tpl)) {
return 'template denied';
}
// 仅允许变量与基础函数
return preg_replace('/{([a-z_]+)}/', '<?php echo $1; ?>', $tpl);
}
?>
除上述代码层修复，还应在Web服务器层面部署规则，拦截包含union select、sleep(等特征的请求。同时升级到官方已修补版本，并定期比对文件哈希，发现被篡改的模板文件立即还原。只有代码加固与运维监控结合，才能切断远程代码执行通道。
任意文件删除漏洞的防护策略
任意文件删除的本质是路径可控。苹果CMS中若出现@unlink($_POST['file'])这类写法，且file参数来自前台，便极易被利用。修复核心是实施真实路径校验与白名单。以下示例展示如何限制删除操作仅能在指定缓存目录内进行。
<?php
$baseDir = realpath('/www/applecms/cache') . DIRECTORY_SEPARATOR;
$userFile = realpath($_POST['file']);
if ($userFile === false || strpos($userFile, $baseDir) !== 0) {
die('invalid path');
}
// 仅允许删除缓存目录下.txt与.tmp
if (!preg_match('/.(txt|tmp)$/', $userFile)) {
die('file type not allowed');
}
unlink($userFile);
?>
在系统层面，还应移除install目录或重命名install.lock为不可写状态，防止重装攻击。对于必须保留的删除接口，建议改为仅限后台管理员操作，并加入CSRF令牌与操作日志。如下表格对比了修复前后的差异，帮助运维快速核对。
| 检查项 | 修复前 | 修复后 |
|---|---|---|
| 路径来源 | 用户直接传入 | realpath校验且限基目录 |
| 文件类型 | 无限制 | 仅txt、tmp |
| 权限控制 | 前台可调用 | 后台+CSRF令牌 |
最后，建议开启PHP的open_basedir限制，将站点可访问目录锁定在根目录下，即使存在遗漏的删除点，攻击者也无法越界删除系统文件。配合文件监控告警，任意文件删除风险可被压制到可接受范围。综合来看，苹果CMS的安全修复是一项系统工程，需从注入、执行、文件操作三方面同步入手，方能真正保障业务持续运行。