feat: 新增备份恢复与公网加固

- 新增备份管理页与 API：在线快照、自动周期备份、按份数清理、下载、一键恢复（恢复前自动兜底）
- 新增 /profile/export，普通用户可导出本人全部数据（不含 Cookie 明文）
- 修复 X-Forwarded-For 可伪造导致三道 IP 防线失效，统一走 client_ip() 取客户端地址
- 取消 admin123 硬编码默认口令，留空则生成随机初始口令并仅打印一次
- .dockerignore 排除 backups/ 并加构建期断言，防止密钥随镜像分发
- 新增会话版本号，改密/停用/删除及恢复备份后其他会话立即失效
- 新增容器资源上限、采集跨度硬顶 31 天、重操作最小间隔与并发 409
- 新增访问日志、HSTS 条件下发、口令黑名单、验证码抗模板匹配、instance.json 0600
- 版本号升至 1.4.0，同步更新 README、SECURITY、.env.example 与 compose 配置

SECURITY.md

@@ -2,14 +2,30 @@
 
 ## 支持范围
 
-本项目按「自托管、局域网内使用」的定位开发。安全修复只针对当前主分支与最新发布版本。
+本项目按「自托管」定位开发，**1.4.0 起已按「可以暴露到公网」加固**（IP 来源、限速、
+资源上限、采集跨度硬顶都补上了），但仍然建议置于反向代理之后。安全修复只针对当前主分支与最新发布版本。
 
 | 版本 | 是否接受安全修复 |
 |---|---|
-| `1.3.x`（当前） | ✅ |
+| `1.4.x`（当前） | ✅ |
+| `1.3.x` | ⚠️ 可用，但**公网暴露前必须升级**（1.4.0 修掉了三道 IP 防线可被 XFF 伪造绕过的问题） |
 | `< 1.3` | ⚠️ 可用，但建议升级（1.3.0 收紧了普通账号的越权面，见下） |
 | `< 1.2` | ❌ 请先升级（1.2.0 修掉了单用户时代「Cookie 明文入库」与「人人都是管理员」两个根本问题） |
 
+> **1.4.0 修掉了什么**（三条 P0）：
+> 1. **`X-Forwarded-For` 可伪造 ⇒ 三道 IP 防线（验证码限速 / 注册配额 / 登录锁定）同时失效**。
+>    实测：每次换一个伪造的 XFF，45 次验证码请求**全部放行**。现在默认不信任 XFF，
+>    全站只有 `security.client_ip()` 一个取客户端地址的入口。
+> 2. **默认口令 `admin123` 硬编码兜底**：现在没有默认口令，留空则生成随机口令、
+>    只在启动日志打印一次、不写进数据库。
+> 3. **`.dockerignore` 漏了 `backups/` ⇒ 凭证密文被打进镜像**：`backups/` 里那份
+>    4.5 MB 的真实库快照含 `settings` 凭证密文与 `users` 口令散列，
+>    `docker build` 会把它烤进镜像层，推一次镜像等于把整库密钥分发出去。
+>
+> 还收掉了一批 P1：采集/导出无跨度上限与频率限制、`WB_COOKIE_SECURE` 默认关且无 HSTS、
+> 账号锁定可被当武器（管理员用户名公开）、撞库不受限、验证码强度不足（可模板匹配）、
+> 改密码不失效其他会话、`instance.json` 未设 `0600`、无访问日志。
+
 > **1.3.0 修掉了什么**：此前「调度时刻 / 采集参数」是**个人级**配置，普通账号可以
 > 自己改（等于让普通账号决定这台服务器怎么发请求、关不关 TLS 校验）；
 > 且 `/logs` 对普通账号开放。现在这两块都收归管理员，普通账号只保留
@@ -43,19 +59,26 @@
 | 项 | 做法 | 位置 |
 |---|---|---|
 | 全站鉴权 | 每个页面都有 `@login_required`，每个 `/api/*` 未登录返回 401 JSON | `security.login_required`、`web/views.py` |
-| 角色（两档） | 管理员 / 普通。**仅管理员**：`/users`、`/api/users*`、`/logs`、`/logs/tail`、`vacuum` | `security.admin_required` |
+| 角色（两档） | 管理员 / 普通。**仅管理员**：`/users`、`/api/users*`、`/logs`、`/logs/tail`、`vacuum`、`/backups`、`/api/backups*`（含下载与**恢复**） | `security.admin_required` |
 | **写权限只有一条规则** | `config.writable_by(key, is_admin)` —— 普通账号能写的只有 `USER_EDITABLE_KEYS = {cookie, user_agent}`（且只限本人那份）。页面与接口共用这一个判断，杜绝「界面置灰但接口还能写」 | `config.writable_by` |
 | **界面置灰 ≠ 安全边界** | 页面上的 disabled / hidden 只是「不给误导性按钮」；真正的闸门是服务端 `@admin_required` 与 `writable_by()`，所以直接敲 URL 或构造请求也过不去 | `web/views.py`、`web/api.py` |
 | 越权写整单拒绝 | 一次提交里只要含不可写的键，整个请求 `400` + `denied` 点名，不做「部分生效」 | `web/api.py:api_settings_post` |
-| 停用即失效 | `current_user()` **每个请求**回查 `users.status`，不等 12 小时会话过期 | `security.current_user` |
+| 停用即失效 | `current_user()` **每个请求**回查 `users.status` **与 `users.session_ver`**，不等 12 小时会话过期 | `security.current_user` |
+| **会话版本号** | 改密码 / 管理员重置口令 / 停用 / **删除**账号 → `bump_session_ver()`，该账号所有其他设备上的会话**立刻作废**。改自己密码时把当前会话刷到新版本（否则改完立刻被自己踢下线）。**恢复备份**会让全站所有会话作废 | `db.session_ver_of` / `db.bump_session_ver` |
 | 自锁保护 | 管理员不能停用 / 降权 / 删除自己；也不能删掉最后一个启用的管理员 | `web/api.py` |
 | CSRF | 所有写请求必须带 `X-CSRF-Token`，页面注入 `window.WB_CSRF`，服务端统一拦截；退出登录也是 POST | `security.check_csrf` |
 | 会话签名 | Flask `secret_key` 由 `data/instance.json` 持有，首次启动随机生成 | `workbuddy_portal/config.py` |
 | 会话 cookie | `HttpOnly` + `SameSite=Lax` + `Path=/`；HTTPS 部署可设 `WB_COOKIE_SECURE=1` 打开 Secure | `workbuddy_portal/__init__.py` |
-| 口令存储 | 加盐哈希（PBKDF2-SHA256），不存明文；强度校验（≥8 位、含两类字符、不得等于用户名） | `security.hash_password` / `password_problem` |
+| **客户端 IP 唯一入口** | `security.client_ip()` —— 默认**不信任** `X-Forwarded-For`（直接用 `remote_addr`）；`WB_TRUST_PROXY=1` 时取**最右侧**合法 IP（最近一跳由你自己的代理写入，客户端伪造不了）。含 `IPv4:port` 与 IPv6 处理。**所有** IP 相关判断（验证码限速 / 注册配额 / 登录限速 / 审计留痕）都走它 | `security.client_ip` |
+| **强制 HTTPS** | `WB_FORCE_HTTPS=1` 时非 HTTPS 的 **GET/HEAD** 跳转（POST 不跳，否则会掉请求体）；`WB_TRUST_PROXY` 关闭时不读 `X-Forwarded-Proto` | `security.needs_https_redirect` |
+| 口令存储 | 加盐哈希（PBKDF2-SHA256），不存明文；强度校验（≥8 位、含两类字符、不得等于用户名）+ **黑名单** `WEAK_PASSWORDS`（34 个撞库字典头几页）。黑名单**只在设置/修改口令时生效**，登录不校验 —— 否则会把用老口令的存量用户挡在门外 | `security.hash_password` / `password_problem` |
+| **初始口令不给默认值** | `WB_ADMIN_PASSWORD` 留空 → `secrets.token_urlsafe(12)` 随机生成，**只在启动日志打印一次、不写进数据库**（审计里出现口令等于永久留档） | `db._create_first_admin` |
 | 开放重定向 | 登录后的 `next` 只允许站内相对路径，`//evil.com` 一律回落到 `/` | `security.safe_next` |
-| 失败限速 | **IP 与用户名两个维度**分别计数，任一维度连续失败 5 次锁 10 分钟；计数表有上限与 TTL | `security.auth_locked` / `note_auth_fail` |
+| 失败限速（双维度、**强度刻意不同**） | **IP 维度**：连续失败 5 次**真锁** 10 分钟。**用户名维度**：只做秒级递增退避（封顶 60 秒）—— 「知道用户名就能把对方锁死 10 分钟」本身是攻击，而**管理员用户名在导航里是公开的**。另有**单来源登录尝试总量** 40 次 / 5 分钟（**含成功**），挡「慢慢撞、不触发失败阈值」。计数表有上限与 TTL | `security.auth_block_reason` / `note_try` / `try_window_left` |
+| 失败提示不泄漏信息 | 提示是「本来源连续失败 N 次」而不是「剩余 N 次」——不给攻击者倒计时 | `web/views.py:login` |
 | 响应头 | CSP（`frame-ancestors 'none'`）、`X-Frame-Options: DENY`、`nosniff`、`Referrer-Policy: same-origin`、COOP；`/api/*` 与 `/captcha*` 带 `no-store` | `security.apply_security_headers` |
+| **HSTS 只在真 HTTPS 时下发** | `COOKIE_SECURE or FORCE_HTTPS` 才发 `Strict-Transport-Security`。纯 HTTP 部署下发会让浏览器强升 https，表现成白屏 —— 很难归因的一类故障 | `security.apply_security_headers` |
+| **访问日志** | waitress 自己不记 access log；本程序补上（跳过 `/static/` 与 `/captcha.png`），写进 `logs/app.log`，`WB_ACCESS_LOG` 控制 | `security._access_log` |
 
 ### 多用户数据隔离
 
@@ -89,17 +112,46 @@
 | 项 | 做法 | 位置 |
 |---|---|---|
 | 图形验证码 | 手写 PNG 编码器 + 5×7 点阵字模 + 干扰线/噪点；**不用 SVG**（SVG 是文本，答案会明文出现在页面源码里） | `workbuddy_portal/captcha.py` |
+| **抗模板匹配** | 让**同一字符两次渲染尽量不同**：逐字符随机旋转 ±22°、切变 ±0.32、缩放抖动、波浪偏移、粗刷笔画（旋转时不断裂）、两色斜向渐变背景、噪点 46 → 70、压线 2~3 条。实测同一验证码两次渲染**字节差异 76.9%**，字符仍可辨认 | `captcha._draw_char` / `captcha._brush_line` |
 | 答案不进会话 | 答案只写服务端 `captchas` 表；会话里仅存随机 id —— Flask 会话是「签名不加密」的，放答案等于送答案 | `security.issue_captcha` |
 | 一次性 | 校验后立即删除，且**先删后判**；5 分钟过期、按 `purpose` 隔离，不能拿注册的题去登登录 | `captcha.verify` |
 | 先验码后验密 | 登录先校验验证码再比对口令，避免攻击者拿「密码对不对」当提前信号跑完字典 | `web/views.py` |
-| 出图限速 | 每来源 60 秒最多 40 张（不设限就是一条廉价的 CPU/带宽放大路径） | `security.captcha_fetch_allowed` |
-| 注册配额 | 同 IP 每日最多注册 N 个（默认 3，可改）；`allow_register=0` 可整体关闭 | `security.register_quota` |
+| 出图限速 | 每来源 60 秒最多 40 张（不设限就是一条廉价的 CPU/带宽放大路径）。**来源按 `client_ip()` 判定**，伪造 XFF 无效 | `security.captcha_fetch_allowed` |
+| 注册配额 | 同 IP 每日最多注册 N 个（默认 3，可改）；`allow_register=0` 可整体关闭。**同样按 `client_ip()` 判定** | `security.register_quota` |
+
+### 资源与频率限制（对外提供服务时）
+
+单写者架构下**不加副本扛负载**，所以限制必须落在「单实例资源」与「单账号频率」两处。
+
+| 项 | 做法 | 位置 |
+|---|---|---|
+| **采集三道闸门** | `POST /api/collect`：① 采集锁存在 → `409`（**有任务在跑就不能新建任务**）；② `action_allowed("collect:uid", gap)` → `429`（默认最小间隔 60 秒）；③ 跨度超上限 → `400` | `web/api.py:api_collect` |
+| **采集跨度硬顶** | `COLLECT_MAX_RANGE_DAYS_HARD = 31`（= 1 个月）。`collect_max_range_days` 只是更严的旋钮，**改大也突破不了** —— 上限由代码兜底，不依赖写入校验。历史脏数据、手工改库都过不去 | `config.COLLECT_MAX_RANGE_DAYS_HARD`、`collect.max_range_days` |
+| 调度时刻数硬顶 | `SCHEDULE_SLOTS_HARD_MAX = 12`，另有可配置的更严上限 `max_schedule_slots_per_day`（默认 6）。时刻数量直接决定采集频次，是「一个账号能不能把云端打满」的开关 | `config.normalize_setting` |
+| 重操作最小间隔 | 采集 60s / CSV 导出 15s / **导出本人数据 10s** / `vacuum` 120s / 补全 prompt 60s / 重算 5s；超限 `429` 并给出剩余等待秒数 | `security.action_allowed` |
+| 容器资源上限 | `cpus: 1.0` / `mem_limit: 512m` / `memswap_limit` **与 `mem_limit` 相等**（= 禁用 swap：超限会「被 OOM 杀掉」而不是「越来越慢」，后者更难查）/ `pids_limit: 256`（挡 fork 炸弹）/ `ulimits.nofile 4096:8192`（SQLite 除主库外还持有 `-wal` `-shm`，恢复期还要开临时库 + `ATTACH` 源库） | `docker-compose.yml` |
+| 线程数受控 | `WB_THREADS`（容器默认 4，代码默认 8）决定单实例能同时吃进几个慢请求；1 核配 8 线程容易出现「都在等 CPU」的假并发 | `config.THREADS` |
+| SSRF 收口 | `api_base` 拒绝云元数据地址（`169.254.169.254` / `metadata.google.internal` / `[fd00:ec2::254]`）—— SSRF 拿云上临时凭证最经典的一跳，且无任何合法采集场景需要它 | `config.normalize_setting` |
+
+### 备份与数据导出
+
+| 项 | 做法 | 位置 |
+|---|---|---|
+| **归档含密钥，这是有意的取舍** | 归档里的 `instance.json` 带 `cookie_key` —— 没有它就永远解不开 `settings` 里的凭证密文，那样的「恢复」等于把所有人的 Cookie 弄丢。代价是**归档本身是最高机密**，因此它**永不入库、永不进镜像** | `backup.INSTANCE_NAME` |
+| **不进镜像** | `.dockerignore` 排除 `backups/`；Dockerfile 在 `COPY` 之后有一条**构建期断言**，`/app/backups` 非空即构建失败。不能靠 `RUN rm` 补救：镜像层是只读叠加的，删掉只会多留一个含内容的中间层 | `.dockerignore`、`Dockerfile` |
+| 文件名收口 | `safe_name()` 对下载与恢复接口吃进来的文件名做 basename 收敛 + 后缀 + 字符白名单（防 `../../etc/passwd`、绝对路径、`sub/..`） | `backup.safe_name` |
+| 防 zip slip | `_extract_safely()` 只按**基名**解压 —— 归档可能是**外部给的**，`extractall` 会因为条目名里的 `..` 写到目录之外 | `backup._extract_safely` |
+| 恢复前护栏 | 自动先给**当前**库打一份 `pre-restore` 快照；恢复错了还能回去 | `backup.restore` |
+| **恢复后全站会话作废** | 所有账号 `session_ver` +1。光靠「从归档里搬 `session_ver`」不够：在打备份**之前**登录的那个人，Cookie 里的 `sv` 正好等于归档里的值，会话会「合法地」活下来，而它描述的账号与权限可能已经被换掉了 | `backup.restore` |
+| 导出不含凭证 | `/profile/export` 给 4 份 CSV/JSON 与说明，**不含 Cookie 明文** —— 导出自己的数据不等于把凭证交出去。10 秒限速 | `web/views.py:profile_export` |
+| 快照用在线备份 API | `Connection.backup` 而不是 `cp`：按页复制并持有读事务，采集正在写也能拿到一致快照。手工 `cp` 一个 WAL 库可能缺最近一段数据，**而且不报错** | `backup._snapshot` |
 
 ### 其它
 
 | 项 | 做法 | 位置 |
 |---|---|---|
-| 容器权限 | 运行层非 root（uid/gid 1000 `app`） | `Dockerfile` |
+| 容器权限 | 运行层非 root（uid/gid 1000 `app`）；`init: true` 让 tini 接管 PID 1，`docker stop` 能干净传到 python | `Dockerfile`、`docker-compose.yml` |
+| **密钥文件权限** | `data/instance.json` 在 POSIX 上显式 `chmod 0600`（默认 umask 022 会留下 0644，同机其他用户可读）。恢复时写回也走同一处理，并先把原文件另存 `.pre-restore-<ts>` | `config._instance_init`、`backup._restore_instance` |
 | 上传体量 | `MAX_CONTENT_LENGTH = 4 MiB` | `workbuddy_portal/__init__.py` |
 | 不索引 | 页面带 `noindex, nofollow` | `web/templates/base.html` |
 
@@ -110,8 +162,13 @@
 `.gitignore` 已覆盖；改动忽略规则后请用 `git check-ignore -v <file>` 逐条复核。
 注意 `.gitignore` **不支持行尾注释**（`path   # 说明` 会让整行变成永不匹配的模式）。
 
+**也绝不进镜像**：`.dockerignore` 里 `backups/` 是**硬要求**，理由见上表（P0-3）。
+`Dockerfile` 里那条构建期断言就是防「以后有人又把它删了」。
+
 > `backups/` 同时也是一个**刻意不放在 `data/`** 的目录：`data/` 在 Docker 部署下是命名卷，
 > `docker compose down -v` 会把备份和正本一起删掉 —— 那正好是最需要备份的时刻。
+> 容器里它挂独立卷 `wb_backups`；**绝不用绑定挂载**（Windows 9p 下容器会
+> `unable to open database file`，且不自愈）。
 
 ## 已知的**非**目标（部署方需自行处理）
 
@@ -120,28 +177,48 @@
 - **没有强制 HTTPS**：请由反向代理（nginx/Caddy）终止 TLS。纯 HTTP 部署时
   **不要**设 `WB_COOKIE_SECURE=1`，否则浏览器不回传会话 cookie（表现为反复被弹回登录页）。
   注意：纯 HTTP 下流量在网内是明文的，同一局域网内的中间人可以看到会话 Cookie 与 Prompt 内容。
+  **反代配置有一个要点**：开启 `WB_TRUST_PROXY=1` 后，程序取 `X-Forwarded-For` 里
+  **最右侧**的合法 IP —— 最右侧是离你最近的那一跳（由你自己的代理写入），客户端加不进去。
+  所以 nginx 写 `$proxy_add_x_forwarded_for`（保留链路，便于排查）或 `$remote_addr`
+  （覆盖）**都安全**；真正不能做的是去信最左边那一段（那是客户端自己填的）。
+  不设反代直接暴露时**必须保持 0**，否则三道 IP 防线全部失效（见 P0-1）。
 - **没有 CSRF 之外的重放防护 / 没有 WAF**：公网暴露前请置于反向代理的 rate limit 之后。
-- **没有备份机制**：备份策略需要你自己定（见 `docs/DEPLOYMENT.md`）。
+  应用层已有采集/导出/恢复等重操作的最小间隔，但那只是「别自己把自己打满」，
+  挡不住分布式来源。
+- **备份策略只做到「本机自动 + 手动下载」**：程序会按周期打快照、按份数清理、支持下载与恢复，
+  但**不会**把归档推到异地。**备份留在同一台机器上只防「改错了」，不防「机器没了」** ——
+  请自行把归档同步到别处（那是 3-2-1 原则里属于你的那一半）。
 - **没有邮件/短信找回**：邮箱只是联系信息，不参与认证；密码忘掉由管理员重置。
-- **不建议直接暴露到公网**：设计前提是局域网或 VPN 内使用。
+- **不建议在没有任何前置防护时直接暴露到公网**：1.4.0 起 IP 来源、限速、资源上限、
+  采集跨度硬顶都补上了，但设计前提仍是「局域网或 VPN 内使用 + 前面有反代」。
 - **Cookie 的获取方式由使用者负责**：手动从浏览器复制、**粘贴给自己的账号**。
   它的权限等同于你的账号，请勿分享给他人；轮换后记得在「配置管理」页更新。
 - **`cookie_key` 泄露 = 所有 Cookie 泄露**：`data/instance.json` 的权限应与数据库同级看待。
+  **备份归档里也有一份 `instance.json`** —— 归档的保密等级与 `instance.json` 完全相同。
 - **管理员在运维层面是可信角色**：能登录部署机器的人可以看到数据库文件、应用日志，
   理论上也能改代码绕过界面限制。所以团队共用时请把「能登服务器」与「日常使用」分开 ——
   界面层的隔离保护的是**使用者之间**，不是「使用者 vs 服务器管理员」。
+  **管理员还能下载备份与执行恢复** —— 这等于对全库数据的完整读写权，授管理员前请想清楚。
 
 ## 部署前的最小检查清单
 
-- [ ] 已修改默认管理员口令（`WB_ADMIN_PASSWORD`），不再是 `admin123`
+- [ ] **未设 `WB_ADMIN_PASSWORD` 时已从启动日志抄下随机初始口令并改掉**
+      （`docker compose logs portal | grep -A6 管理员初始口令`）—— 现在**没有** `admin123` 兜底
 - [ ] 已确认是否要开放自助注册；开放时按需调小 `register_max_per_ip`
-- [ ] `data/` 与 `logs/` 目录的权限只对服务账号可读写（内含 `instance.json` 的两个密钥）
+- [ ] `data/`、`logs/`、`backups/` 的权限只对服务账号可读写（前两者与 `instance.json` 同级机密）
 - [ ] 前面有反向代理并启用了 HTTPS；若是 HTTPS，已设 `WB_COOKIE_SECURE=1`
+- [ ] **反代是否重写了 `X-Forwarded-For`**：是 → `WB_TRUST_PROXY=1`
+      （`$proxy_add_x_forwarded_for` 或 `$remote_addr` 均可，程序取最右侧）；
+      否（含直接暴露）→ **保持 `WB_TRUST_PROXY=0`**。这条搞错会让三道 IP 防线同时失效
+- [ ] 容器资源上限符合预期（`docker stats` 看 `MEM LIMIT` 是否为 512MiB；`docker inspect` 看 `PidsLimit`）
 - [ ] 确认 `data/instance.json` 没有被提交到任何仓库
-- [ ] `backups/` 也未被提交，且已确认 `.gitignore` 生效（`git check-ignore -v backups/x.sqlite`）
-- [ ] 已规划备份（SQLite 库是唯一正本）；备份文件同样受 `cookie_key` 保护，需按机密对待
-- [ ] 新增的账号一律用**普通角色**；只有确实需要维护实例的人才给管理员
+- [ ] `backups/` 也未被提交，且已确认 `.gitignore` 生效（`git check-ignore -v backups/x.zip`）
+- [ ] **确认镜像里没有备份归档**：`docker run --rm <镜像> sh -c 'ls -A /app/backups'` 应为空
+- [ ] 已规划**异地**备份：程序只负责本机打快照，归档需自行同步到别的机器/对象存储
+- [ ] 新增的账号一律用**普通角色**；只有确实需要维护实例的人（含**下载备份与恢复**）才给管理员
+- [ ] 已把「采集最小间隔 / 单次最长跨度 / 每日时刻上限」三个刹车调到符合你的预期
+      （「任务管理」页可改；跨度硬顶 31 天不可突破）
 - [ ] 升级后登录一次「配置管理」，确认 Cookie 状态为「已配置」而不是
       「已保存但无法解密」
-- [ ] 升级到 1.3.0 后确认「任务管理」里调度时刻**对普通账号是只读的**
-      （用普通账号点一次「保存」应被拒并点名越权项）
+- [ ] 升级到 1.4.0 后确认「任务管理」里调度时刻**对普通账号是只读的**，
+      且访问 `/backups` 返回 403（用普通账号各试一次）