本文由 FlintHub 开发文档归档发布。原始文档日期见标题前缀，来源：暂存20260913/FlintHub_深度架构审计报告_20260904.md。

FlintHub 深度架构审计报告

审计模型： MiMo-V2.5-Pro

审计日期： 2026-09-04

审计范围： app/Controllers/ (30) · app/Helpers/ (24) · app/SplitDB/ (12) · plugins/ (27)

审计维度： 跨层调用 · 权限逻辑 · 数据一致性 · 潜在越权

一、架构概览（正面发现）

审计覆盖的 13 个前台 + 16 个后台控制器 均通过以下机制保护：

二、🔴 高风险（HIGH）— 5 项

H-1 · 核心 Helper 读退役表：搜索功能在 SplitDB 后遗漏新帖

代码片段：

// 第 313 行 — 退役表 COUNT 查询
$cnt = $db->fetchOne(
    "SELECT COUNT(*) as count FROM threads t WHERE (t.title LIKE :q1 OR t.content LIKE :q2) AND t.deleted_at IS NULL" . $catFilter . $timeFilter,
    \array_merge([':q1' => $sq, ':q2' => $sq, ':since' => $since], $catParams)
);

// 第 321 行 — 退役表分页查询
$rows = $db->fetchAll(
    "SELECT t.*, u.username, c.name as category_name FROM threads t LEFT JOIN users u ON t.user_id = u.id LEFT JOIN categories c ON t.category_id = c.id WHERE (t.title LIKE :q1 OR t.content LIKE :q2) AND t.deleted_at IS NULL{$catFilter}{$timeFilter} ORDER BY t.created_at DESC LIMIT ...",
    \array_merge([':q1' => $sq, ':q2' => $sq, ':since' => $since], $catParams)
);

H-2 · 核心 Helper 读退役表：附件清理逻辑扫描遗漏新内容

代码片段：

// 第 613-617 行 — 退役表扫描（threads/posts 在 SplitDB 后不再有新数据）
$contentTables = [
    'SELECT content FROM threads WHERE content LIKE :p',  // ← 退役表
    'SELECT content FROM posts WHERE content LIKE :p',    // ← 退役表
    'SELECT content FROM blogs WHERE content LIKE :p',    // ← 未分片，保留
];

H-3 · 插件权限强制模式默认关闭：权限声明形同虚设

代码片段：

// Plugin.php 第 112-121 行
public static function requirePermission(string $name, string $perm): bool
{
    if (self::granted($name, $perm)) return true;

    $enforce = \app\Helpers\Settings::get('permission_enforce', '0') === '1'; // 默认 '0' = 警告模式
    $action = $enforce ? 'DENY' : 'warn';
    \error_log("[plugin-permission] {$action} [{$name}] missing permission '{$perm}'");
    \app\Helpers\AuditLog::log('plugin_permission', 'plugin', 0, "{$action} [{$name}] missing permission '{$perm}'");
    return !$enforce; // 警告模式下始终返回 true（放行）
}

H-4 · 插件直写核心表：mod_system 绕过 User Model 修改用户组

代码片段：

// Plugin.php 第 375-381 行 — 封禁：直写核心表
$banGroupId = (int)self::getSetting('ban_group_id');
if ($banGroupId > 0) {
    $coreDb->query(
        'UPDATE users SET group_id = :g WHERE id = :u',
        [':g' => $banGroupId, ':u' => $uid]
    );
}

// Plugin.php 第 404-409 行 — 解封：直写核心表
if (!empty($ban['original_group_id'])) {
    $coreDb->query(
        'UPDATE users SET group_id = :g WHERE id = :u',
        [':g' => (int)$ban['original_group_id'], ':u' => (int)$ban['user_id']]
    );
}

H-5 · 插件直写核心表：red_packet 直接修改用户积分

代码片段：

// Plugin.php 第 80-125 行 — 创建红包：直写核心表积分
$db->begin();
try {
    $userRow = $db->fetchOne('SELECT points FROM users WHERE id = :id', [':id' => $userId]);
    if (!$userRow || (int)$userRow['points'] < $totalPoints) {
        throw new \RuntimeException(\app\Helpers\I18n::get('plugin.red_packet.err_points'));
    }
    // ↓ 直写核心表，绕过 Points Helper
    $db->query('UPDATE users SET points = points - :p WHERE id = :id', [':p' => $totalPoints, ':id' => $userId]);
    // ... 后续单独 INSERT points_log（与 Points Helper 事务语义不一致）
    $db->commit();
}

三、🟡 中风险（MEDIUM）— 4 项

M-1 · 13 个插件直查核心库用户表（绕过 User Model）

问题描述： 批量补用户名属于读操作（SELECT id, username FROM users WHERE id IN (...)），安全风险较低，但违反"插件用独立库"的架构规范。若核心库连接池满或锁竞争，这些直查会成为瓶颈。

修复建议： 在 User Model 或新 Helper 中提供 User::batchGetNames(array $ids): array 方法，封装核心库查询 + 请求级缓存（同 Permission::groupIdOf() 的缓存策略），插件统一调用。

M-2 · mod_system 用原生 SQL 物理删除核心表记录

代码片段：

// AdminController.php 第 268-272 行
case 'blog_comment':
    try {
        // ↓ 原生 SQL 物理删除，无级联清理
        \app\Core\Database::getInstance()->query(
            'DELETE FROM blog_comments WHERE id = :id', [':id' => $id]);
    } catch (\Throwable $e) { \error_log('[mod_system] blog_comment delete: ' . $e->getMessage()); }
    break;

M-3 · seo 插件声明缺失 system:settings 权限

M-4 · notifications 插件权限声明不完整

四、🟢 低风险（LOW）— 3 项

L-1 · seo/FrontController.php 未使用的 Database 实例

L-2 · 插件用 file_get_contents 读本地文件（非网络请求）

问题描述： 以上均为本地文件读取，不涉及 SSRF。与 Plugin::http() 无关（后者仅管控外部 HTTP 请求）。

修复建议： 无需修改。code_repo 的文件读取已有 realpath + 前缀校验，边界安全。

L-3 · 搜索 Helper 未走分片索引的全文匹配

五、汇总统计

六、总体评价

FlintHub 核心层（控制器 / Helper / SplitDB）的安全架构设计完善：

• 认证体系： Auth::isAdmin() 双重校验（role + group_id），前台 requireLogin() 覆盖所有写操作
• CSRF 防护： 20+ POST 处理器无遗漏，敏感操作（改密码/删帖子）额外消费 Token 防重放
• 权限校验： Permission::check() 白名单 + 请求级缓存 + 游客回退机制，无绕过路径
• SSRF 防护： Plugin::http() + ApiController::fetchImage() 双重 IP/域名校验
• SplitDB 设计： 连接池 LRU + 活动事务保护 + 原子写入 + web 访问防护

主要风险集中在：

1. SplitDB 迁移不彻底 — 核心 Helper（Search / Settings）仍有 2 处读退役表，影响搜索和附件清理功能正确性
2. 插件跨层调用 — 2 个插件（mod_system / red_packet）直写核心表绕过 Model 层，13 个插件直查核心库用户表
3. 权限强制模式 — 默认关闭，权限声明体系无实际约束力

建议优先级：

1. 立即修复： H-1（搜索）+ H-2（附件清理）—— 功能性缺陷，影响用户可见
2. 短期修复： H-3（权限强制）+ H-4/H-5（直写核心表）—— 安全架构完整性
3. 中期优化： M-1 ~ M-4 —— 架构规范收敛
4. 低优先级： L-1 ~ L-3 —— 代码质量

报告由 MiMo-V2.5-Pro 模型生成 · 审计范围为源码静态分析 · 未执行运行时验证