Smail/docs/安全审查工程优化审核报告.md

Smail 工程优化审核报告

审核日期：2026-08-24
审核基线：e91a641 重命名项目并补充插件与安全整改文档
审核分支：main
审核范围：当前工作区 D:\Desktop\Smail，依据 docs\安全审查风险整改任务清单.md 对 SEC-001 至 SEC-022 进行工程优化与安全整改复核。
审核结论：本轮未发现可以标记为“复审通过”的任务；整改清单中的 22 项状态保持不变。

一、审核结论摘要

当前项目可以完成前端生产构建，部分后端单元包测试通过，但尚不具备安全上线条件。主要阻断原因如下：

1. SMTP 587 端口在 STARTTLS 建立前允许认证，并且认证日志会输出密码。
2. 初始化接口暴露在普通 HTTP 服务上，缺少一次性令牌、来源限制、速率限制和失败次数限制。
3. HttpsEnabled == 2 时，HTTP 直接承载完整业务路由和会话。
4. 密码认证仍使用固定盐 MD5；登录、初始化、改密、管理员重置和 SMTP 登录没有统一的新凭据验证服务。
5. 邮件移动、分组删除和 IMAP UID 查询存在用户归属校验缺口。
6. 请求体、邮件附件和 Base64 解码后的内容没有形成统一的大小限制策略。
7. 未形成统一 CSRF、防安全响应头、插件隔离、TLS 证书校验和依赖漏洞审计流程。
8. go vet ./... 仍然失败；全量 go test ./... 存在删除真实配置和数据库的测试副作用，未在当前工作区执行。

因此，建议先完成 P0 全部整改，再进入 P1 的认证、租户隔离和输入安全整改，最后完成 P2 的工程加固和 CI 门禁。

二、复审状态总览

任务编号	优先级	审核状态	结论	关键证据
SEC-001	P0	未通过	不通过	backend/listen/smtp_server/smtp.go:28 在 587 端口设置 AllowInsecureAuth = true
SEC-002	P0	未通过	不通过	backend/listen/smtp_server/action.go:68,92,96 记录用户名、密码和完整用户对象
SEC-003	P0	未通过	不通过	setup_server.go:27-29,52-58 暴露初始化服务；业务拦截只按 /api/setup 放行
SEC-004	P0	未通过	不通过	http_server.go:69-90 在关闭 HTTPS 时仍注册业务路由和会话
SEC-005	P1	未通过	不通过	group.go:123-126 只校验邮件所属用户，未校验目标分组所属用户
SEC-006	P1	未通过	不通过	group.go:88 更新 user_email 时缺少 user_id 条件
SEC-007	P1	未通过	不通过	utils/password/encode.go 使用两次 MD5 和固定字符串盐
SEC-008	P1	未通过	不通过	多个控制器直接 io.ReadAll(req.Body)；附件缺少统一数量、总量和解码后大小限制
SEC-009	P1	未通过	不通过	路由使用 mux.HandleFunc，未见统一 HTTP 方法和 CSRF 防护中间件
SEC-010	P1	未通过	不通过	邮件清理允许全局 style、<style> 和远程图片；前端使用 v-html
SEC-011	P1	未通过	不通过	缺少统一安全响应头；插件 iframe 未设置 sandbox
SEC-012	P1	未通过	不通过	SSL 初始化仅 os.Stat 用户路径并直接写入配置，未做受控目录和匹配校验
SEC-013	P1	未通过	不通过	utils/smtp/smtp.go:80 设置 InsecureSkipVerify = true
SEC-014	P1	未通过	不通过	backend/main_test.go:35-36 删除真实配置和数据库
SEC-015	P2	未通过	不通过	配置、证书和公钥文件使用 0666，配置目录使用 0755
SEC-016	P2	未通过	不通过	services/auth/auth.go:45 生成 1024 位 RSA DKIM 密钥
SEC-017	P2	未通过	不通过	附件下载使用错误的 ContentType 响应头，文件名直接拼接到响应头
SEC-018	P2	未通过	不通过	config.go:264-273 使用字符串判断绝对路径，未使用平台无关路径边界校验
SEC-019	P2	原始审查不通过，复审通过	通过（生产模式失败关闭）	已完成插件白名单、最小环境、Linux 独立用户、chroot 临时根目录、网络命名空间和资源限制；Windows 等不具备隔离能力的平台生产模式拒绝插件启动
SEC-020	P2	未通过	不通过	detail.go:79 UID 查询只按 id，未加入当前用户条件
SEC-021	P2	未通过	不通过	未安装 govulncheck；前端只有 yarn.lock，没有统一锁文件和 CI 扫描门禁
SEC-022	P2	未通过	不通过	go vet ./... 报告 7 处未命名结构体字段问题，CI 未执行 vet

三、逐项工程审核

1. P0 上线阻断项

SEC-001：SMTP 587 在 STARTTLS 前认证

审核结果：不通过。

backend/listen/smtp_server/smtp.go:28 将 587 端口的 AllowInsecureAuth 设置为 true。当前配置会使 SMTP 服务器可能在 TLS 升级前声明并接受认证能力，与任务清单要求的“仅 STARTTLS 成功后认证”不一致。

优化要求：

• 587 端口必须在 TLS 建立前不返回 AUTH 能力。
• STARTTLS 失败、未执行 STARTTLS 或连接降级时必须拒绝认证。
• 465 端口保持隐式 TLS，并与 587 使用不同的启动方式。
• 增加 SMTP 协议级回归测试，验证 STARTTLS 前后 EHLO 能力和认证结果。

SEC-002：SMTP 日志泄漏凭据

审核结果：不通过。

backend/listen/smtp_server/action.go:68 使用日志输出用户名和明文密码；action.go:92 在认证成功时输出完整用户对象，action.go:96 在认证失败时再次输出用户名和密码。该问题属于凭据直接泄漏，必须优先处理。

优化要求：

• 日志中不得出现密码、密码哈希、完整用户对象或第三方认证密钥。
• 认证日志只保留请求 ID、脱敏账号、结果、来源地址和失败原因分类。
• 为认证失败日志增加敏感字段回归测试或日志审计测试。

SEC-003：初始化接口保护不足

审核结果：不通过。

backend/listen/http_server/setup_server.go:27-29 将初始化 API 挂载到初始化 HTTP 服务，setup_server.go:52-58 直接监听端口。backend/listen/http_server/https_server.go:135-137 在未初始化时仅按路径 /api/setup 放行，没有发现一次性初始化令牌、失败次数限制、速率限制或受控来源校验。

优化要求：

• 初始化服务默认只允许本机或显式配置的受控来源访问。
• 使用一次性、短时效的初始化令牌，并在初始化成功后立即失效。
• 对初始化失败进行速率限制和失败次数限制。
• 初始化完成后，初始化 API 必须永久返回拒绝，不得依赖前端隐藏入口。

SEC-004：明文 HTTP 承载登录会话

审核结果：不通过。

backend/listen/http_server/http_server.go:69-90 在 HttpsEnabled == 2 时直接注册完整业务路由，并通过 session.Instance.LoadAndSave(mux) 启用会话。当前未见统一的 HTTPS 强制策略、Cookie Secure、HttpOnly、SameSite、HSTS 以及安全响应头配置。

优化要求：

• 生产模式禁止使用明文 HTTP 承载登录和业务会话。
• HTTP 仅允许健康检查、ACME 挑战或重定向到 HTTPS。
• 会话 Cookie 必须设置 Secure、HttpOnly 和合理的 SameSite。
• 在 TLS 终止于反向代理时明确可信代理边界，并验证转发协议头。

2. P1 高优先级整改项

SEC-005：邮件移动目标分组归属

审核结果：不通过。

backend/services/group/group.go:123-126 的更新语句只通过 email_id 和 user_id 限制被更新的邮件，但直接使用请求传入的 groupId，没有先确认目标分组属于 ctx.UserID。攻击者可以尝试引用其他用户的分组 ID。

**优化要求：**先查询并锁定目标分组的 id + user_id，不存在或不属于当前用户时拒绝操作；再在同一事务内更新邮件，并增加双用户隔离回归测试。

SEC-006：删除分组后的邮件更新

审核结果：不通过。

backend/services/group/group.go:88 的 update user_email set group_id=0 where group_id in (...) 没有附加 user_id 条件，存在跨用户修改邮件分组的风险。分组统计查询也存在按 group_id 查询而未统一附带用户条件的路径。

**优化要求：**删除分组、清理邮件和统计查询均必须同时带当前用户条件；删除和清理操作必须在同一事务中完成，并增加失败回滚测试。

SEC-007：统一密码哈希与凭据验证

审核结果：不通过，且与既定整改原则直接冲突。

backend/utils/password/encode.go 使用两次 MD5 和固定字符串盐。当前登录、初始化、改密、管理员重置和 SMTP 登录仍使用旧 password.Encode 路径；HTTP 临时令牌也依赖 MD5 计算。项目没有 Argon2id、统一 PasswordService 或 CredentialValidator。

优化要求：

• 删除旧算法运行时兼容路径，不保留 MD5 与新算法双轨验证。
• 使用 Argon2id，并将算法参数、盐和版本信息保存在密码哈希值中。
• 登录、初始化、改密、管理员重置和 SMTP 登录统一调用同一凭据验证服务。
• 第三方配置验证所需的可逆密钥不得使用密码哈希保存，应使用受控加密存储；日志不得打印明文。
• 既有账号统一通过密码重置或重新初始化设置新密码，不在登录时自动兼容旧 MD5。

SEC-008：请求体与附件大小限制

审核结果：不通过。

登录、初始化、用户、设置、规则、分组、邮件和插件接口存在直接 io.ReadAll(req.Body) 的读取方式。邮件附件 Base64 解码未形成单附件、总附件数、总请求体、解码后大小和超时的统一限制，存在内存消耗风险。

**优化要求：**在统一中间件使用 http.MaxBytesReader 或等价机制，按接口分类设置上限；附件在解码前后都校验大小，限制数量、总量和 MIME 类型，并对超限返回明确错误。

SEC-009：CSRF 与 HTTP 方法限制

审核结果：不通过。

路由统一使用 mux.HandleFunc，未发现状态修改接口的统一方法限制、CSRF Token、Origin 或 Referer 校验中间件。Cookie 会话下的删除、移动、发信、改密、用户和规则操作需要统一保护。

**优化要求：**状态修改接口拒绝 GET，采用 CSRF Token 与可信来源校验组合；登录、初始化等特殊流程单独定义认证边界，并增加跨站请求回归测试。

SEC-010：邮件 HTML 清理与展示隔离

审核结果：不通过。

backend/dto/parsemail/email.go:122,129,132,140-141 允许全局 style、img 的 style、a 的 style 及 <style> 元素，并允许远程图片。frontend/src/views/EmailDetailView.vue:52 使用 v-html 将邮件 HTML 直接插入主页面 DOM。虽然已有 bluemonday 和 XSS 测试基础，但当前策略仍过宽，且缺少邮件展示专用隔离环境。

**优化要求：**严格收紧 HTML 白名单，默认禁止脚本、事件属性、危险 URL、远程资源和 CSS 行为；优先使用邮件专用受限 iframe，配合 sandbox 和邮件专用 CSP；补充 CSS、URL、SVG、表单和重定向测试。

SEC-011：安全响应头与插件 iframe

审核结果：不通过。

当前 HTTP 拦截器主要设置 Content-Type，未发现统一设置 CSP、X-Content-Type-Options、Referrer-Policy、Permissions-Policy 等安全响应头。frontend/src/components/PluginSettings.vue:12 的 iframe 没有 sandbox，也没有明确的来源、权限和通信边界。

**优化要求：**建立统一安全响应头中间件；插件 iframe 使用最小权限 sandbox，限制来源和可用能力，避免访问主应用 Cookie、DOM 和敏感 API。

SEC-012：初始化 SSL 路径与证书私钥校验

审核结果：不通过。

backend/controllers/setup.go:148-162 只使用 os.Stat 检查用户提交的证书和私钥路径，backend/services/setup/ssl/ssl.go:54-77 直接把路径写入配置。未发现受控目录、路径穿越、符号链接逃逸、文件类型和证书私钥匹配校验。

**优化要求：**使用受控证书目录和 filepath.Clean，拒绝目录、符号链接逃逸和工作区外路径；解析证书与私钥并验证公钥匹配，错误信息不得泄漏敏感路径内容。

SEC-013：出站 SMTPS 证书校验

审核结果：不通过。

backend/utils/smtp/smtp.go:79-82 设置 InsecureSkipVerify: true，出站 SMTPS 默认跳过证书链和主机名校验，容易遭受中间人攻击。

**优化要求：**默认启用证书验证和主机名校验；如确有企业自签证书场景，使用显式受控 CA 配置，不提供无条件跳过校验的默认路径。

SEC-014：测试副作用

审核结果：不通过，且本轮未执行全量测试。

backend/main_test.go:35-36 在 TestMain 中直接删除 config/config.json 和 config/smail_temp.db，并以当前工作目录启动主服务。为遵守“未经同意不删除任何文件”的约束，本轮没有执行 go test ./...。

**优化要求：**测试使用临时目录、测试专用配置和测试端口；通过依赖注入或测试启动器隔离数据库和配置。整改后在隔离环境执行 go test ./...，并验证测试前后工作区文件校验和不变。

3. P2 加固与质量项

任务	审核结论与证据	优化方向
SEC-015	不通过：config.go:215,226,242 和 services/setup/ssl/ssl.go:141-151,225-235 使用 0666 写入敏感文件，目录使用 0755。	私钥使用 0600，配置按最小权限创建，目录权限按运行账户和平台策略收紧。
SEC-016	不通过：services/auth/auth.go:45 使用 rsa.GenerateKey(rand.Reader, 1024)。	改为至少 2048 位，并增加密钥长度回归测试和旧密钥轮换策略。
SEC-017	不通过：controllers/attachments.go:47-48 使用错误的 ContentType 头名称，文件名直接拼接 Content-Disposition，未设置 nosniff。	使用标准响应头、RFC 兼容文件名编码、文件名清理、X-Content-Type-Options: nosniff，并补充 CRLF 和路径字符测试。
SEC-018	不通过：config.go:264-273 通过是否以 / 开头判断绝对路径。	使用 filepath.IsAbs、filepath.Clean 和目录边界校验，覆盖 Windows 盘符、UNC、相对路径和符号链接场景。
SEC-019	原始问题已整改：生产模式仅启动可建立隔离的插件，不满足隔离条件时失败关闭。	已实现白名单、最小环境、Linux 独立用户、chroot、网络隔离和资源限制；Windows 生产模式拒绝不可隔离插件。
SEC-020	不通过：services/detail/detail.go:76-80 的 UID 分支按 id 查询，缺少 user_id = ctx.UserID。	所有 UID、邮件 ID、附件 ID 查询统一绑定用户条件，增加跨用户 IMAP 回归测试。
SEC-021	不通过：当前环境未安装 govulncheck 和 yarn.cmd；前端存在 yarn.lock 但没有 package-lock.json，发布工作流只构建不扫描。	明确单一前端包管理器和锁文件，CI 执行 Go 与前端依赖扫描，并设置发布阻断或安全例外审批。
SEC-022	不通过：go vet ./... 报告 email.go 4 处、controllers/group.go 3 处未命名结构体字段；发布工作流未执行 go vet。	修复 keyed struct literal，并将 go vet ./... 设为合并前门禁。

四、已执行验证

验证项	命令	结果
前端构建	cd frontend; npm.cmd run build	通过；Vite 构建成功，但存在单个 JavaScript 包超过 500 kB 的性能警告，建议后续代码分包。
后端重点包测试	go test ./utils/password ./dto/parsemail ./utils/address ./utils/utf7 ./services/rule/match	通过。
静态检查	cd backend; go vet ./...	失败；发现 7 处未命名结构体字段问题。
Go 全量测试	cd backend; go test ./...	未执行；backend/main_test.go 会删除真实配置和数据库，需先隔离测试环境。
Go 依赖模块枚举	cd backend; go list -m all	可执行；仅证明模块可解析，不等同于漏洞扫描。
Go 漏洞扫描	govulncheck ./...	未执行；当前环境未安装 govulncheck。
前端依赖审计	npm audit 或 yarn audit	未形成可复现流程；前端锁文件和包管理器尚未统一。

五、整改优先级与验收顺序

第一阶段：P0 上线阻断

1. SEC-001：修复 587 STARTTLS 前认证。
2. SEC-002：清理 SMTP 敏感日志。
3. SEC-003：保护初始化入口并设置一次性令牌。
4. SEC-004：禁止明文 HTTP 承载业务会话。

第二阶段：认证与隔离

1. SEC-007：以 Argon2id 和统一凭据服务替换旧 MD5 运行时路径，不保留旧算法兼容逻辑。
2. SEC-005、SEC-006、SEC-020：补齐邮件、分组和 IMAP UID 的用户归属条件。
3. SEC-008、SEC-009：统一请求限制、CSRF 防护和 HTTP 方法限制。
4. SEC-010、SEC-011：收紧邮件内容展示并隔离插件 iframe。
5. SEC-012、SEC-013：限制 SSL 文件路径并恢复出站 TLS 校验。

第三阶段：工程质量和持续安全

1. SEC-014：隔离全量测试，不再触碰真实配置和数据库。
2. SEC-022：修复 vet 并建立静态检查门禁。
3. SEC-015 至 SEC-019：完成权限、密钥、附件、路径和插件边界加固。
4. SEC-021：建立 Go、前端依赖漏洞扫描和发布阻断流程。

六、整改后的统一验收基线

整改完成后，必须至少通过以下验证：

• SMTP：587 在 STARTTLS 前不返回 AUTH，TLS 建立后才能认证；465 使用隐式 TLS。
• 认证：登录、初始化、改密、管理员重置、SMTP 登录统一通过凭据验证服务；不再执行 MD5 兼容校验。
• 第三方配置：需要向第三方发起连接的密钥使用受控加密存储，不使用不可逆密码哈希代替可逆密钥。
• 会话：HTTP 不承载业务会话；Cookie 具备 Secure、HttpOnly、SameSite；响应头和 HSTS 策略可验证。
• 初始化：令牌一次性、短时效、失败限速；初始化完成后接口失效。
• 隔离：双用户邮件、附件、分组、IMAP UID 交叉访问均被拒绝。
• 输入：请求体、附件数量、附件总量、解码后大小和处理超时均有上限。
• 内容：邮件 HTML 严格清理，远程资源策略明确，邮件与插件在隔离容器或受限 iframe 中展示。
• 测试：go test ./... 在临时目录执行，go vet ./... 成功，测试不会改变工作区真实文件。
• 依赖：Go 和前端锁文件、漏洞扫描结果、CI 运行记录可追溯到提交和构建产物。

七、审核边界和遗留风险

• 本报告是工程优化审核结果，不代表任何整改项已经完成，也不替代后续代码复审。
• 本轮没有修改业务源码，没有删除文件，没有修改整改清单中的任务状态，也没有提交或推送新的 Git 变更。
• 前端构建通过不代表 XSS、会话和插件隔离风险已解决。
• 重点包测试通过不代表整个服务、SMTP、初始化流程和跨用户边界已通过验证。
• 全量 Go 测试、Go 漏洞扫描和前端依赖漏洞扫描仍需在整改后、隔离环境中完成。

复审补充：SEC-019

2026-08-24 复审时，SEC-019 已按生产失败关闭原则完成整改。Linux 生产模式使用独立 UID/GID、chroot 临时根目录、默认无网络命名空间和资源限制；Windows 及其他平台无法建立同等隔离时拒绝生产插件启动。