2 Commits

Author	SHA1	Message	Date
JianFeeeee	0f8ca6894a	fix(webui): 限流来源识别改为「只信任受信反代的 XFF」—— 修复把自己锁在门外 ... ★ 这是在生产上亲手踩出来的：上一提交加了按 IP 限流后，我用 8 次错误登录 做验证，结果**把管理员自己锁在外面 10 分钟**。 ## 现场证据 [webui] POST /api/v1/login from=127.0.0.1 auth=none status=429 webui 经 frp/nginx 穿透到公网时，**所有外部请求的 RemoteAddr 都是 127.0.0.1**。于是所有人共用一个桶：任何人爆破 5 次，就把**所有人** （含管理员）一起锁死。限流从防护变成了 DoS。 ## 我第一版还犯了个方向的错 当时我刻意**不采信** X-Forwarded-For，理由是「该头可伪造，换个头就能 绕过限流」。这个理由本身对，但结论下反了：完全不采信，在穿透部署下 **必然退化成全局限流** —— 而全局限流正是我试图避免的那个后果。 ## 正确做法：中间路线 **只信任受信反代发来的 XFF**。判定「是否来自受信反代」不能靠 内网/回环 IP 猜 —— 穿透部署下反代恰恰就在本机 127.0.0.1，与直连请求 完全同源，猜不出来。所以由部署方**显式声明**（新设置项 `webui.trusted_proxies`，逗号分隔 CIDR 或裸 IP）。 权衡写明：未声明时穿透明场景下限流退化为「全局」。这是**刻意的保守 默认** —— 宁可限流偏保守，也不能因为采信伪造头而形同虚设。 ## 判据（+4） - TestLoginRateLimitUsesForwardedForFromTrustedProxy：受信反代下按真实 客户端 IP 隔离（否则就是全局锁） - TestLoginRateLimitIgnoresUntrustedForwardedFor：换 XFF 头不得绕过限流 - TestLoginRateLimitNeedsExplicitTrustedProxyConfig：未配置 = 不采信 - TestParseTrustedProxies：合法项接受、非法项丢弃、空 = nil 全量：35 包全绿。 ★ 附带教训（也记在判据注释里）：**用失败注入做验证时要意识到副作用 范围**。我那次「跑 8 次错误密码看看会不会限流」本身是合理的验证动作， 但它作用在**生产实例**上，且限流的作用域（全局化）正好覆盖了自己。 在带状态的安全机制上做破坏性验证，判据应该先证明作用域是对的。	2026-09-26 13:49:59 +08:00
JianFeeeee	b4c6b17721	fix(webui): 登录入口加固 —— 限流 + 常量时间比对 + 请求体限量 + 防用户名枚举 ... 门户可经 frp 穿透到公网（https://homeagent.jianfgit.xyz/ 实测直达）， 而 handleLogin 原先是**零防护**：无限流、无失败计数、口令用 == 明文比对、 失败不审计。等于把唯一��口令入口直接开到外网任人爆破。 ## 改动 1. **按来源 IP 的失败计数限流**（login_limiter.go） - 5 次失败后拦，10 分钟窗口。 - 退避而非永久封禁：窗口过期自动恢复。永久封禁意味着一旦误撞 （或被撞库）就再也登不进，只能上机器改配置。 - 成功即清零：手滑输错几次不该被永久记账。 - **刻意不采信 X-Forwarded-For** —— 该头可伪造，直接采信等于让 攻击者换一个头就能绕过限流，甚至把限流当成打别人来源的武器。 代价（已在注释写明）：若 webui 挂在反代后，限流会退化成「全局」， 那种部署应在反代层限流或用 PROXY protocol 传真实来源。 - **刻意不做账号级锁定**：本系统只有一个管理员账号，账号级锁定 相比 IP 级无额外收益，却多一个误伤面。 - 过期记录会被 prune —— 否则攻击者轮换 IP 就能喂成内存泄漏。 2. **常量时间比对**（crypto/subtle）：`==` 会在第一个不同字节处短路， 泄漏「猜对了几位」的时序信息。 3. **请求体限量**：ContentLength 前置拒绝 + MaxBytesReader 兜底。 ★ 后者**不能只靠解码器报错** —— json.Decoder 按需读流，遇到 「超大 + 非法 JSON」会在第 0 字节就报语法错误、永远读不到上限， 于是 8MB 数据已进缓冲而 MaxBytesError 从未出现。只挂 MaxBytesReader 的写法对最省力的攻击载荷反而无效（实测确认）。 4. **防用户名枚举**：用户不存在与口令错误给完全相同的状态码与报文。 ## 判据（8 条） 限流触发 / 按来源隔离（否则一个 IP 就能把所有人锁死，限流即 DoS）/ 成功清零 / Retry-After / 请求体限量 / 防枚举 / 过期清理 / 重试时长非零。 变异验证（3 条打红后还原）： - 去掉限流调用 → 3 条判红 - 去掉 ContentLength 前置检查 → 判红（回到 400） - 去掉 Reset → **起初没打红**：原判据「跑 30 次看是否限流」在阈值只有 5 时无论有没有 Reset 都会限流，是条**假判据**。已改为**测出实际阈值** （清零后应重新拿到完整额度），再去变异即打红。 诚实说明：常量时间比对那条**无法用单测可靠断言**（时序属性，噪声远大于 信号）。它由代码评审保证，不由测试保证 —— 写明以免后人以为有测试兜着。	2026-09-26 13:49:59 +08:00