Why

Xiuno BBS 4.0.4 早已停止维护，遗留大量安全漏洞、PHP8 适配兼容问题、底层架构短板，同时生态长期碎片化。

目前社区缺少一套基于原版完整源码、一事一文档的结构化缺陷佐证资料。

此前我在 xiunobbs.cn 发布过二十余篇重构解析文章，但不少读者看完依旧无法清晰区分 Xiuno X 相较于原版做了哪些升级优化。

本文档规范计划对 xiunobbs_4.0.4/ 原版源码开展完整深度审计，每一处问题单独生成独立 Markdown 文件。

一方面为后续开发者重构方案提供可溯源、可核对的事实依据；
另一方面可供不愿迁移至 Xiuno X 的开发者，自行对照审计文档针对性修复改造；
同时也能直观对照出 Xiuno X 已完成的全部修复与升级内容。

What Changes

• 新建审计输出目录 ./audit_404/，按四类前缀分类存放缺陷文档

• 每一条经源码核实的缺陷独立生成一个 md 文件（一问题=一文件，严禁合并）

• 每个文档采用固定四段结构：# 标题 → ## 现象 → ## 源码证据（带真实文件路径与行号 + 代码片段）→ ## 风险等级与结论（含危害说明 + 修复建议）

• 全部文档生成后创建 audit_404/index.md 汇总目录索引

• 创建 Trae Work 专用 Skill：.trae/skills/xiuno_audit_split/SKILL.md

• 创建配套输出规则：.trae/rules/output_rule.yaml（强制一事一文）

• 生成可一键打包的压缩包 xiuno404_defect_docs.zip

Impact

• 受影响代码：xiunobbs_4.0.4/ 全部 PHP/HTML/JS 源码（约 70+ 文件）

• 重点关注目录：xiunophp/（db 抽象层）、model/（业务模型）、route/（前端路由）、*****/route/（后台路由）、install/（安装目录）、view/htm/（模板）、conf/（配置）、model.inc.php、index.inc.php

• 不修改任何 Xiuno 源码，仅产出审计文档

ADDED Requirements

Requirement: 一事一文输出约束

审计文档 SHALL 严格遵守"一个独立问题 = 一个 md 文件"。禁止把多条缺陷写入同一文档；禁止在一个文档中附带与主题无关的其他缺陷。

Scenario: 单文件内容边界

• WHEN 审计发现一个缺陷

• THEN 该缺陷独立写入一个 md 文件，文件内只描述该缺陷的现象、源码证据、风险与建议，不涉及其他缺陷

Requirement: 文档固定四段结构

每个缺陷文档 SHALL 包含且仅包含四个一级/二级标题段落：

1. # 问题：<标题> —— 一级标题，简明陈述问题

2. ## 现象 —— 描述缺陷表现与触发条件

3. ## 源码证据 —— 引用真实源码，必须包含文件相对路径 + 行号 + 代码块

4. ## 风险等级与结论 —— 标注风险等级（高危/中危/低危/兼容障碍/架构缺陷/生态缺陷），说明危害后果，给出修复建议

Scenario: 源码证据可追溯

• WHEN 文档声称某缺陷存在

• THEN 必须给出 xiunobbs_4.0.4/ 下的真实文件路径、行号区间、原代码片段，审计读者可凭此定位到源码

Requirement: 按真实源码审计

文档内容 SHALL 以 xiunobbs_4.0.4/ 实际源码为准，不得照抄需求清单中与源码不符的描述。若需求清单条目与源码实际不符，应基于真实源码重新表述缺陷论点，或在证据中说明"清单描述失实，实际缺陷为……"。

Scenario: 清单失实条目处理

• WHEN 需求清单描述与真实源码不符（例如清单称"全程 mysql_* 废弃函数、无 PDO 预处理"，但实际 db 层有 db_mysql/db_pdo_mysql 抽象类，仅转义方式为 addslashes 而非 PDO 预处理）

• THEN 文档按真实源码重写论点（如改为"db 抽象层使用 addslashes 转义而非 PDO 预处理，存在宽字节注入与转义绕过风险"），并保留缺陷的有效性

Requirement: 尽可能挖掘全部问题

审计 SHALL 不局限于需求清单列出的 24 条候选条目，对源码进行全面扫描，凡在真实源码中可定位证据的安全/兼容/架构/生态缺陷均应生成独立文档。需求清单作为候选引导，不作为上限。

Scenario: 发现清单外缺陷

• WHEN 审计过程中发现清单未列出的真实缺陷（如 SSRF、任意文件包含、弱加密算法、硬编码密钥、信息泄露等）

• THEN 同样为该缺陷生成独立 md 文件，归入对应分类目录

Requirement: 文件命名与分类

文档 SHALL 输出到 ./audit_404/，按四类前缀命名：

• 01_critical_xxx.md —— 高危安全类（SQL 注入、XSS、CSRF、上传、密码、会话、安装目录等）

• 02_compat_xxx.md —— PHP8 兼容障碍类（废弃函数、移除特性、字符集、严格模式报错等）

• 03_struct_xxx.md —— 底层架构缺陷类（MVC、插件沙盒、全局变量、缓存、接口层等）

• 04_plugin_xxx.md —— 插件与主题生态缺陷类（编码规范、钩子冲突、主题硬编码、版本碎片化等）

Scenario: 文件归类

• WHEN 审计确认一条 SQL 注入缺陷

• THEN 文件命名为 01_critical_<具体短描述>.md，存放在 audit_404/ 下

Requirement: 目录索引

全部缺陷文档生成后 SHALL 创建 audit_404/index.md，按四类分组列出所有文档的相对链接，并在每组前注明类别说明。

Scenario: 索引可用

• WHEN 用户打开 audit_404/index.md

• THEN 可看到全部缺陷文档的分类链接列表，点击可跳转到对应文档

Requirement: Skill 与规则文件

SHALL 创建 .trae/skills/xiuno_audit_split/SKILL.md（Skill 定义，含 name/description/allowed-tools/globs/执行规则）与 .trae/rules/output_rule.yaml（强制一事一文的输出规则），内容以本 spec 与用户原始需求为蓝本。

Scenario: Skill 可调用

• WHEN 后续在其他 Xiuno 项目中调用 xiuno_audit_split Skill

• THEN Skill 按既定规则触发审计流程，输出符合本 spec 的文档集

Requirement: 打包发布

全部文档生成后 SHALL 执行 zip -r xiuno404_defect_docs.zip ./audit_404/ 生成可发布到 Gitee 的压缩包。

Scenario: 打包完成

• WHEN 所有 md 与 index.md 已生成

• THEN 工作目录下存在 xiuno404_defect_docs.zip，解压后为完整的 audit_404/ 目录结构

审计条目范围（候选清单，按真实源码核实后生成）

01 高危安全类（候选 8 条 + 挖掘新增）

1. db 抽象层用 addslashes 转义而非 PDO 预处理，存在 SQL 注入风险（含宽字节）

2. 用户密码存储方式（MD5+盐 vs 现代哈希，需核实 route/user.php 与 model/user.func.php）

3. GET/POST 变量直接拼接进 SQL（核实 db_cond_to_sqladd 与各 route 文件）

4. 存储型 XSS，模板输出未统一 htmlspecialchars

5. 文件上传校验机制（后缀黑名单 vs 白名单 vs MIME）

6. 后台操作 CSRF 令牌防护情况

7. install 安装目录未自动清理，可重置数据库

8. Cookie 未设置 HttpOnly/Secure/SameSite

02 PHP8 兼容障碍类（候选 5 条 + 挖掘新增）

1. mysql_* 系列函数在 PHP8 移除（核实 db_mysql.class.php 与 install/index.php）

2. create_function() / each() 在 PHP8 移除

3. 正则 /e 修饰符废弃

4. 仅 utf8 字符集，不支持 utf8mb4

5. 严格模式下未定义变量、数组越界

03 底层架构缺陷类（候选 6 条 + 挖掘新增）

1. 纯面向过程，无 MVC 分层

2. 插件钩子点不足

3. 无插件运行沙盒（plugin_compile_srcfile 直接合并编译）

4. 全局变量泛滥

5. 缓存类型支持情况（核实 conf.default.php 已支持 redis/memcached，需重新表述为"默认配置仅 mysql 缓存，未默认启用 Redis"或剔除该条）

6. 无统一接口层，AJAX 散乱

04 插件与主题生态缺陷类（候选 5 条 + 挖掘新增）

1. 插件无统一编码规范，可篡改全局函数（overwrite 机制）

2. 不同插件共用钩子冲突

3. 老主题硬编码数据库查询

4. 插件仅适配 PHP7

5. 插件版本碎片化