|
|
3273c507b3
|
fix(webui): Server 读侧超时（防 Slowloris）+ 反向判据守住流式不被腰斩
http.Server 原本**一个超时都没设**（只有 Handler）。后果是 Slowloris：
攻击者只占连接不发完整请求头，每个连接挂几 KB。MaxHeaderBytes 限的是
头部**大小**，「慢慢发」不占大小、不受它约束，几百个连接就能耗尽 fd。
## 为什么不是「把超时都设上」
webui 有一条长连接 SSE（/api/v1/chat/events）与可跑 300s 的流式
/v1/chat/completions。WriteTimeout 是「从请求开始到响应写完」的**总预算**，
会把它们腰斩 —— 表现为 SSE 每隔一段时间断一次、前端疯狂重连。而这类
回归在功能测试里很难立刻发现。
所以只设读侧三项，各管一段：
ReadHeaderTimeout 20s —— 请求头必须按时发完，Slowloris 的正解
ReadTimeout 60s —— 读完整请求（含 body）的预算，防慢速上传
IdleTimeout 120s —— keep-alive 空闲连接（另两项都管不到）
WriteTimeout 0 —— **刻意不设**（见上）
## 判据（3 条，含一条反向判据）
- TestServerHasReadSideTimeouts：三个读侧超时都必须 > 0
- TestServerHasNoWriteTimeout：**反向**钉住 WriteTimeout 必须保持 0，
防止将来有人「顺手补全超时」把 SSE 弄坏
- TestSSEConnectionSurvivesBeyondReadTimeout：SSE 连接确实活过读侧窗口
反向判据看着琐碎，但它守的正是「这次没做的那件事」——
不加 WriteTimeout 是个**决定**，不是疏漏，所以要用判据把决定固定下来。
变异验证：补上 WriteTimeout:30s → 反向判据判红；
去掉 ReadHeaderTimeout → 前向判据判红。
测试脚手架注意：newServerForTest 绑 127.0.0.1:0（内核分配空闲端口），
绝不用 :8080 —— 那是生产端口（见 a752ae1）。
全量：35 包全绿。
|
2026-09-26 13:49:59 +08:00 |
|
|
|
35df6f4366
|
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 |
|
|
|
5ebc4481b0
|
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 |
|
