极小的攻击面，公开的审查

Exchange 应用程序访问策略决定了影响范围的边界。下面每一条发现都被它兜住——即便凭据被完全攻陷，也只能以一个共享邮箱的名义发信，别的什么都做不了。这也是为什么安装指南把这条策略当作附带验证命令的必做步骤，而不是可选的加固。

v0.1.1 的代码树在首次上线部署之后接受了审计——Graph 传输层、设置模型、测试邮件 API 方法和 Vue 组件，逐一检查机密是否会通过日志、API 响应、HTML 源码和浏览器控制台泄露；检查 API 接口上的身份验证与 CSRF；检查每一项设置的输入校验；以及确认 Graph 的错误内容除超级用户之外还会不会被别人看到。凡是关于 Matomo 行为的说法，都对照 Matomo 源码做了核实，而不是凭记忆。

发布之前已修复

• 基础 URL 覆盖参数原本可能把客户端密码指向攻击者的主机——现在所有 URL 在构建请求之前都会被校验为纯粹的 https 源。
• 上传中途的网络故障原本可能把带预授权的上传 URL 泄进日志——现在它会像其他所有失败一样被转换并脱敏。
• 设置项原本接受任意字符串——现在每个字段都会校验自己的格式，因此粘错的密码 ID 会在保存时就失败，而不是稍后变成一条看不懂的 Microsoft 错误。
• 测试邮件 API 方法原本接受任意收件人并响应 GET——现在改为仅接受 POST、地址必须通过校验，并且不会进入服务器访问日志。

核实无问题

• 机密绝不会出现在 HTML 源码、API 响应或浏览器控制台里——密码字段由 Matomo 核心负责遮蔽，插件还在其之上加了两道自己的防护。
• 测试调用受 Matomo 令牌模型的 CSRF 保护，并额外增加了仅允许 POST 的规则作为纵深防御。
• 所有被记录或抛出的内容都会经过一个脱敏器，它按值清除已知机密、按形态清除各类凭据——令牌、断言、bearer 请求头、上传 URL——并且在异常时选择失败而不是放行。

已记录在案的可接受取舍

• 短时有效的访问令牌缓存在 Matomo 基于文件的缓存里——能读到它的人本来就能读到 Matomo 的配置，而配置里可能就存着密码本身。55 分钟的有效期和访问策略缓解了这一点。
• 超级用户可以不受限流地发送测试邮件——这是骚扰向量，不是提权向量；超级用户本来就能直接把邮件配置改掉。
• 在设置界面输入的密码会以明文存放在 Matomo 数据库中——配置文件和环境变量这两层正是为了让它不必如此而存在，而且它们的优先级更高。

在 GitHub 上阅读包含全部十一项发现的完整审查报告

请把详情发送到下面这个地址。也请给我们在问题公开之前把它修好的机会——另外，报告里请永远不要附上客户端密码、证书或 PEM 文件。

安全联系方式: …