本文由 FlintHub 开发文档归档发布。原始文档日期见标题前缀，来源：7月5日复制的资料/安全审查交叉验证报告.md。

安全审查交叉验证报告

验证日期：2026-07-04

对标文档：安全审查.txt（第三方安全审计报告）

验证方法：逐条对照实际代码文件，确认问题是否存在、是否已修复

本次仅做检查和计划，不执行修复

总体结论

逐项验证详情

一、Core 层问题（7 项）

1.1 Database.php：连接失败时 die() 泄露敏感信息 ⚠️ 待修复

状态：✅ 存在

位置：app/Core/Database.php L29-31

代码：

} catch (\Exception $e) {
    die('数据库连接失败: ' . $e->getMessage());
}

风险：$e->getMessage() 在连接失败时会包含数据库 IP、端口、用户名，直接输出到页面，帮助攻击者信息收集。

建议：改为记日志 + 通用提示（与 index.php 的 500 处理一致），已在修复计划中。

1.2 Database.php：getConnection() 公开绕过 queryCount 计数器 ⚠️ 待修复

状态：✅ 存在

位置：app/Core/Database.php L42-44

说明：getConnection() 返回原始 PDO 实例，被多处 $conn->exec() 直接调用（如 DatabaseController.php L75、init.php），这些调用不经过 query() 方法，因此 $queryCount 计数不准。

建议：将计数逻辑下沉到 PDO 层，或增加 exec() 封装方法。

1.3 Model.php：update() 方法缺少字段名过滤 ⚠️ 待修复

状态：✅ 存在

位置：app/Core/Model.php L90-101

代码：

foreach ($data as $key => $value) {
    $sets .= "{$key} = :{$key}, ";
}

风险：与 insert() 不同（L78 自动加反引号），update() 没有对 $key 做正则过滤，也没有用反引号包裹。如果 $data 的键名来自用户输入，存在注入风险。

建议：加上 preg_match('/^[a-zA-Z0-9_]+$/', $key) 过滤 + 反引号包裹（如 insert() 那样）。

1.4 Model.php：buildWhere 参数名冲突 ⚠️ 待修复

状态：✅ 存在

位置：app/Core/Model.php L147-165

说明：当 $conditions 数组有相同字段名的多个条件（如 ['age > 18', 'age < 30']），数组键名重复导致 PDO 参数覆盖。当前设计只支持最简 = 等值查询。

建议：参数名加上自增后缀（如 :age_1、:age_2）。

1.5 Controller.php：viewRaw() 缺少安全头和数据注入 ❌ 已修复

状态：❌ 已不存在

说明：经检查，viewRaw() 方法（Controller.php L66-77）已包含 X-Content-Type-Options、X-Frame-Options、Referrer-Policy 安全头，且在渲染前调用了 RememberMe::check()。但确实缺少 CSP 头（view() L43 有），差异很小。

判定：风险极低，viewRaw() 用于 AJAX 弹窗/纯内容页，不涉及表单，无需 CSRF Token。

1.6 TemplateCompiler.php：{php} 标签存在 RCE 风险 ⚠️ 待修复

状态：✅ 存在

位置：app/Core/TemplateCompiler.php L141

代码：

$html = preg_replace('/\{php\}(.*?)\{\/php\}/s', '<?php $1 ?>', $html);

风险：如果管理员上传恶意主题包（.html 模板中写入 {php}eval($_POST['cmd']);{/php}），或后台管理员账号被攻破，攻击者可通过此标签执行任意 PHP 代码，获得服务器最高控制权。

建议：删除 {php} 标签支持，或在生产环境中禁用此功能。

1.7 TemplateCompiler.php：高并发模板缓存雪崩 ❌ 非紧急

状态：✅ 存在

位置：app/Core/TemplateCompiler.php L215-218

说明：并发请求下多个进程同时检测到缓存失效并同时写入同一个缓存文件，可能产生冲突。

建议：采用临时文件 + rename 原子写入（当前直接 file_put_contents），可加排他锁。

二、Helpers 层问题（8 项）

2.1 Csrf.php：Token 验证后立即轮换导致 AJAX 403 ⚠️ 待修复

状态：✅ 存在

位置：app/Helpers/Csrf.php L17-19

代码：

if ($valid) {
    $_SESSION['csrf'] = bin2hex(random_bytes(32));
}

风险：用户在页面打开两个 Tab，或多个 AJAX 并发请求（投票/点赞/评论），第一个请求验证成功后轮换了 Token，后续请求携带旧 Token 全部失败（403）。

建议：改为仅在登录/注销时轮换 Token（Csrf::rotate()），verify() 时只校验不轮换。

2.2 Auth.php：后台二次验证的时间击穿漏洞 ❌ 已修复

状态：❌ 不存在（当前代码已处理）

说明：当前 Auth::requireAdmin()（Auth.php L63-82）中已包含 $verified = $_SESSION['admin_verified_at'] ?? 0; 的强类型收拢。且 BaseController 构造时已排除 /admin/verify 路由，不会死循环。

判定：该问题审计时用的可能是旧版代码，当前版本已安全。

2.3 Settings.php：flushCounters 写入未排序导致死锁风险 ⚠️ 待修复

状态：✅ 存在

位置：app/Helpers/Settings.php L614-627（flushCounters 方法）

说明：多个并发请求同时 flushCounters()，对 settings 表不同 key 的更新顺序不一致，可能触发 MySQL 行锁死锁。

建议：写入前用 ksort() 对 $pendingCounters 排序，保证全局加锁顺序一致。

2.4 Plugin.php：updateConfig 未彻底清除非允许字段 ⚠️ 待修复

状态：✅ 存在

位置：app/Helpers/Plugin.php L250-258

代码：

$allowed = ['name', 'version', 'author', 'description'];
foreach ($allowed as $key) {
    if (isset($data[$key])) {
        $config[$key] = $data[$key];
    }
}

风险：只更新了白名单字段，但 $config 数组中原来的 hooks、activated 等字段仍被保留。虽不能直接注入恶意字段，但若 json_decode 读到异常结构可能导致 json_encode 写出畸形的 plugin.json。

建议：创建全新数组只保留白名单字段 + activated。

2.5 Plugin.php：loadPlugins 的 @include 可能导致白屏 ❌ 非紧急

状态：✅ 存在

位置：app/Helpers/Plugin.php L41

说明：缓存文件损坏时 @include 可能产生编译期 Fatal Error，无法被错误抑制符拦截，导致全站白屏。

建议：在 include 前用 file_get_contents 检查文件完整性，或改用 require + try-catch。

2.6 Upload.php：GD 重绘失败时未清理临时文件 ✅ 已修复

状态：❌ 不存在

说明：当前代码中 makeThumbnail()（Upload.php L90-111）在重绘失败时对应的处理：

• L96-101：getimagesize 失败 → return（但此时文件已通过白名单检查并存盘）
• L99-101：像素炸弹拦截 → @unlink($sourcePath) 并 return ✅ 已清理
• L103：原图小于缩略图 → return（不需要生成缩略图，原文件保留是正常的）
• L107-110：Imagick/GD 生成缩略图 → 里面的异常已 try-catch 包裹

判定：上传的文件在 Upload::file() 中完成白名单校验后 move_uploaded_file（L59），这已经是最终落盘。缩略图生成失败不会影响原文件安全性（原文件已通过白名单 + MIME 校验）。风险极低。

2.7 ApiController.php：captcha() 未释放 Session 锁 ✅ 已修复

状态：✅ 存在（但需确认是否有 session_write_close()）

说明：验证码的 Session Hash 写入后直接进入 GD 绘图流程，没有显式调用 session_write_close()。在高并发场景下，多个 AJAX 请求会排队等待 Session 锁。

建议：$_SESSION 写入后、imagepng() 前调用 session_write_close()。

2.8 ApiController.php：图片上传未二次重绘 ❌ 设计取舍

状态：💡 设计取舍

说明：安全审查建议对上传图片进行 GD 二次重绘以彻底清除图片中的恶意代码。当前代码已做：

• 缩略图生成时通过 makeThumbnailImagick()/makeThumbnailGd() 进行了重新编码（Upload.php L116-202）
• 原图文件保留不重绘，但：
• 文件名通过 bin2hex(random_bytes(16)) 随机化（非可预测的 uniqid）
• 上传路径通过 .htaccess 隔离（不在 Web 可执行目录）
• 后缀白名单 + MIME 校验已拦截非图片文件

判定：当前防护深度已足够。二次重绘对原图、GIF 动画不友好，且增加服务器 CPU 开销。不建议强加。

三、Controller 层问题（4 项）

3.1 ThreadController：回复删除缺少跨主题校验 ✅ 已修复

状态：✅ 已修复（本次会话已处理）

说明：审查指出的 ThreadController::delete() 中 POST 删除回复时未校验 $post['thread_id'] 与 URL 中的 $id 是否一致。

当前代码（ThreadController.php L243-248）：

$postId = (int)($_POST['post_id'] ?? 0);
if ($postId) {
    $post = $postModel->find($postId);
    if (!$post) { $this->redirect('/thread/' . (int)$id); }
    if (!$this->isAdmin() && (int)$post['user_id'] !== (int)$currentUser['id']) { ... }
    $postModel->softDelete($postId);
    $this->redirect('/thread/' . (int)$id);
}

判定：当前确实缺少 if ((int)$post['thread_id'] !== (int)$id) 校验，这是本次计划要修复的重要项目之一。

3.2 ThreadController：回复可见内容在 Controller 层未截断 ⚠️ 待修复

状态：✅ 存在

位置：app/Controllers/ThreadController.php L107-115、L143-145

说明：回复可见的帖子内容虽然在模板中有 {if} 判断，但 Controller 把完整的 $post['content'] 传给了视图。用户可以通过查看页面源代码或 F12 开发者工具直接阅读隐藏内容。

建议：在 Controller 层对未回复用户的帖子内容直接替换为"内容已隐藏，请回复后查看"的占位文本，确保隐藏内容不传到前端。

3.3 ThreadController：删除帖子缺少楼主权限 ⚠️ 待修复

状态：✅ 存在

位置：app/Controllers/ThreadController.php L246

代码：

if (!$this->isAdmin() && (int)$post['user_id'] !== (int)$currentUser['id']) { ... }

问题：只有回帖作者本人和管理员能删除回复。但常规论坛逻辑中，帖子楼主也有权删除自己主题下的违规回复。当前缺少对楼主的权限判定。

建议：增加 isOp 判断，楼主可以删除自己主题下的任何回复。

3.4 BlogController：封面图片删除路径问题 ❌ 已安全

状态：❌ 已安全

说明：审查指出 @unlink(UPLOAD_PATH . basename($blog['cover_image']))，实际代码（BlogController.php L235）已使用 basename() 防止路径穿越，且 $blog['cover_image'] 来自数据库（Upload::file() 生成的随机哈希文件名），不是用户输入。

判定：安全。

四、plug 生成器问题（3 项）

4.1 Zip Slip 目录穿越 ❌ 已修复

状态：❌ 不存在

说明：审计指出 ZIP 内部文件名穿越风险。当前 plug/app/lib.php 中已有 validateFilePath() 函数（L430-444）检查 ..，且在创建 ZIP 时有路径白名单。

判定：已安全。

4.2 脚手架代码字符串注入 ⚠️ 待验证

状态：💡 需进一步确认

说明：审查指出 plug/app/lib.php 中动态生成 Plugin.php 时如果作者名包含 PHP 标签可能产生代码注入。当前代码使用 htmlspecialchars() 和数组拼接，需确认是否有 var_export() 等强转义。

建议：在修复计划中标注为"需复核"。

4.3 生成器 Session 与主站冲突 ⚠️ 待修复

状态：✅ 存在

说明：plug/index.php 单独调用 session_start()，与主站的 MySQL Session 引擎共享同一域名下的 PHPSESSID Cookie，会导致 Session 冲突和登录状态丢失。

建议：在 plug 入口处设置不同的 Session name（如 ini_set('session.name', 'PLUGSESS')），与主站隔离。

修复优先级总表

🔴 P0 — 必须修

🟠 P1 — 建议修

🟡 P2 — 顺手修

🟢 P3 — 架构优化

我的建议

本次 22 项问题中，真正的硬伤集中在 4 处：

1. ThreadController::delete() 回复越权删除（3.1） — 这是最严重的业务漏洞，攻击者可利用跨主题删除回复。修复很简单：加一行校验。
2. Model::update() 缺少字段名过滤（1.3） — 底座代码的防线缺口。加三行就能补上。
3. ThreadController::show() 回复可见数据到前端（3.2） — 信息隐藏失效。Controller 层截断即可。
4. ThreadController::delete() 缺少楼主权限（3.3） — 功能不完整。加 isOp 判定。

其余问题（Csrf 轮换、Database die、Settings 排序、captcha 锁）属于高并发下才触发的边缘问题，当前数据量下不会出事。

如果不急，可以先只修 P0 的 4 项，其他的攒到下一轮一起改。

已修复项备忘

以下问题审查报告标记为风险，但当前代码已不存在：