[B-07][medium] mochi 报错日志会写出整个包：CONNECT 里的密码与会话令牌、PUBLISH 正文进入日志 #14

New Issue

2026-09-30T13:56:52+08:00

nixevol commented

2026-09-30 13:56:52 +08:00

编号：B-07　严重级：medium　工作线：broker（internal/broker）　来源：审查 P-12
依赖：无　被依赖：无

结论与统一方案

采用审查 P-12 的方案：broker.New 给 mochi 单独的 logger，包一层 slog.Handler，把类型为 packets.Packet 或 *packets.Packet 的属性替换成摘要（包类型、QoS、包号、主题、正文长度），其余原样转发给原来的 handler。同时核对 broker 自身日志没有打印 payload、password、session_token。

PRD §8 明确要求日志无正文、无密码、无令牌，属于安全缺陷。默认 info 级别就能触发（同一连接发第二个 CONNECT、3.1.1 设备 QoS1 发到别人的主题等）。

改动文件

internal/broker/broker.go 或新建 internal/broker/log.go。

与其他问题的交互 / 冲突说明

独立，不改钩子逻辑；与 broker 线其他 issue 只在 New 函数相邻。

验收与测试

捕获日志；登录后在同一连接再发一个带已知密码的 CONNECT，日志里既没有明文也没有它的 base64。
3.1.1 客户端用 QoS 1 发到别人的主题，日志里不含正文。
debug 级别下发送失败的日志也不含 hello 响应里的 session_token。

问题明细（各区审查原文，证据含文件与行号）

以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。解决方案以本 issue 上方的"结论与统一方案"为准；原文里的方案与之不一致时，按上方执行。

[P-12] mochi 日志会把整包写出来：CONNECT 里的密码和会话令牌、PUBLISH 的正文

严重级：medium
分类：安全
现象与影响：
- broker 把 slog.Default() 直接交给了 mochi。mochi 在处理包出错时会用 Warn 级别记录整个包（字段名 "pk"）。
- packets.Packet 的字段都是导出的，Connect.Password 还带 json:"password" 标签，JSON 日志会把密码和 Payload 以 base64 写出来。
- 默认 info 级别就能触发的路径：
  - 同一连接上发第二个 CONNECT：密码或 nst_ 令牌进日志；
  - MQTT 3.1.1 设备用 QoS 1 发到不是自己 up 的主题：正文进日志，其中可能有 talk_password 或改登录密码时的新旧密码；
  - 格式不合法的 PUBLISH。
- debug 级别下，mochi 发送失败时也会记录整包，而下行的 hello 响应里带 session_token。
证据：broker.go:147-151；mochi server.go:520-530、678-682、733-737、866-874；clients.go:196-201；server.go:1016-1019；packets/packets.go:151-156。
文档依据：PRD 第 8 节「日志无正文、无密码、无注册安全码、无令牌」；DEVELOPMENT 12、15。
为何不是故意设计：没有记录。
解决方案：在 broker.New 里给 mochi 单独的 logger：包一层 slog.Handler，把类型为 packets.Packet 或 *packets.Packet 的属性替换成摘要（包类型、QoS、包号、主题、正文长度），其余原样转发给原来的 handler。
改动文件：internal/broker/broker.go（或新建 log.go）
与其他模块的交互/冲突风险：broker 自己的日志不受影响。
需补测试：捕获日志输出；登录后再发一个带已知密码的 CONNECT，确认日志里既没有明文也没有它的 base64；3.1.1 客户端用 QoS 1 发到别人的主题，确认日志里不含正文。
置信度：代码阅读确定

_{复审基线：main 4059a15（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。}

**编号**：B-07　**严重级**：medium　**工作线**：broker（internal/broker）　**来源**：审查 P-12 **依赖**：无　**被依赖**：无 ### 结论与统一方案采用审查 P-12 的方案：`broker.New` 给 mochi 单独的 logger，包一层 `slog.Handler`，把类型为 `packets.Packet` 或 `*packets.Packet` 的属性替换成摘要（包类型、QoS、包号、主题、正文长度），其余原样转发给原来的 handler。同时核对 broker 自身日志没有打印 payload、password、session_token。 PRD §8 明确要求日志无正文、无密码、无令牌，属于安全缺陷。默认 info 级别就能触发（同一连接发第二个 CONNECT、3.1.1 设备 QoS1 发到别人的主题等）。 ### 改动文件 `internal/broker/broker.go` 或新建 `internal/broker/log.go`。 ### 与其他问题的交互 / 冲突说明独立，不改钩子逻辑；与 broker 线其他 issue 只在 `New` 函数相邻。 ### 验收与测试 - 捕获日志；登录后在同一连接再发一个带已知密码的 CONNECT，日志里既没有明文也没有它的 base64。 - 3.1.1 客户端用 QoS 1 发到别人的主题，日志里不含正文。 - debug 级别下发送失败的日志也不含 hello 响应里的 `session_token`。 --- ### 问题明细（各区审查原文，证据含文件与行号） > 以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。**解决方案以本 issue 上方的"结论与统一方案"为准**；原文里的方案与之不一致时，按上方执行。 #### [P-12] mochi 日志会把整包写出来：CONNECT 里的密码和会话令牌、PUBLISH 的正文 - **严重级**：medium - **分类**：安全 - **现象与影响**： - broker 把 `slog.Default()` 直接交给了 mochi。mochi 在处理包出错时会用 Warn 级别记录整个包（字段名 `"pk"`）。 - `packets.Packet` 的字段都是导出的，`Connect.Password` 还带 `json:"password"` 标签，JSON 日志会把密码和 Payload 以 base64 写出来。 - 默认 info 级别就能触发的路径： - 同一连接上发第二个 CONNECT：密码或 nst_ 令牌进日志； - MQTT 3.1.1 设备用 QoS 1 发到不是自己 up 的主题：正文进日志，其中可能有 talk_password 或改登录密码时的新旧密码； - 格式不合法的 PUBLISH。 - debug 级别下，mochi 发送失败时也会记录整包，而下行的 hello 响应里带 session_token。 - **证据**：`broker.go:147-151`；mochi `server.go:520-530`、`678-682`、`733-737`、`866-874`；`clients.go:196-201`；`server.go:1016-1019`；`packets/packets.go:151-156`。 - **文档依据**：PRD 第 8 节「日志无正文、无密码、无注册安全码、无令牌」；DEVELOPMENT 12、15。 - **为何不是故意设计**：没有记录。 - **解决方案**：在 `broker.New` 里给 mochi 单独的 logger：包一层 `slog.Handler`，把类型为 `packets.Packet` 或 `*packets.Packet` 的属性替换成摘要（包类型、QoS、包号、主题、正文长度），其余原样转发给原来的 handler。 - **改动文件**：`internal/broker/broker.go`（或新建 `log.go`） - **与其他模块的交互/冲突风险**：broker 自己的日志不受影响。 - **需补测试**：捕获日志输出；登录后再发一个带已知密码的 CONNECT，确认日志里既没有明文也没有它的 base64；3.1.1 客户端用 QoS 1 发到别人的主题，确认日志里不含正文。 - **置信度**：代码阅读确定 --- <sub>复审基线：main `4059a15`（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。</sub>