  luckoneandClaude Code
|
ee8929115e
|
refactor(web): 通知页拆分为组件，1095 行降到 605 行
页面此前接近 1100 行，超过 CLAUDE.md 的 800 行硬上限。按项目的 _components/
约定拆开，每个文件都能单独读懂：
_components/channel-fields.ts 渠道字段表与配置值解析（纯数据，无视图）
_components/channel-form.tsx 按字段定义渲染控件的表单
_components/delivery-list.tsx 投递记录表与筛选
_components/stat-tile.tsx 概览统计卡片
page.tsx 只负责编排：加载、表单状态、调接口
拆分是纯模块搬移，未改行为；tsc 与 next build 均通过，/system/notify 仍正常
预渲染。
Co-Authored-By: Claude Code <[email protected]>
|
2026-09-30 16:25:06 +08:00 |
|
|
luckoneandClaude Code
|
a049f09b97
|
fix(notify): 安全审计修复 —— 掩码绕过、SSRF、静默丢失等 12 项
对推送功能做了一轮安全审计，每条都先复现、再修、再补回归测试。
以下按严重程度排列。
【严重】掩码可被「改目标地址、保留凭据」绕过
目标地址与凭据是两套独立字段，而配置合并对「未提及的键」保留原值。于是
只改地址、对凭据避而不谈，服务端就会把库里的真凭据发到任意地址。已实测
复现四个渠道：通用 Webhook 的 Authorization 头、Telegram 的 Bot Token
（进请求路径）、邮件的 SMTP 密码（STARTTLS 后交给对端）、钉钉/飞书的加签
密钥（该项不可利用，一并列出仅为说明面）。完全静默、不依赖重定向，所以
上一轮加的「拒绝跨主机跳转」挡不住它。
修法：新增 Channel.DestinationKeys() 声明「消息发往哪」，PrepareConfigUpdate
在地址变化时要求对**每一个**凭据字段显式表态（给新值，或显式留空表示不再
需要）——原样回传掩码值等于「沿用旧凭据」，正是攻击形状，一并拒绝。
刻意不做「自动丢弃凭据」：对可选字段（如 headers）那会变成「鉴权静默没了
但接口返回成功」，比报错更难排查。
【中】markdown 系三渠道对不可信内容零转义
钉钉/企微/飞书此前完全不转义（Telegram 与邮件都做了），而标题与摘要来自
模型输出、资产 url 来自被测目标。一条标题里的 `[文字](http://evil)` 会在
工程师的钉钉里变成可点击外链；`` 会被客户端拉取，
泄露阅读者 IP 并暴露「这条已被看过」。现统一单行化 + markdown 元字符转义。
修的过程中还纠了自己一个设计错误：转义一度被放进 markdownTitle，而它被
markdown 正文、Telegram 的 HTML、飞书卡片、Webhook 的 JSON 与邮件主题四种
语境共用，markdown 的反斜杠泄漏到了 Telegram 消息里（用户会看到 `\(1\)`）。
转义必须发生在各自的渲染出口——测试直接抓到了这个回归。
【中】投递地址的 SSRF 面
此前只校验 scheme 与 host，云元数据 169.254.169.254、环回、内网一律可投递；
而失败响应体前 200 字节会进 last_error 并被投递历史接口回显，构成半盲读
原语。现在在**拨号阶段**设防（最终生效点，同时覆盖 DNS 重绑定与同主机
重定向）。环回/链路本地需显式 ARTEX_NOTIFY_ALLOW_LOCAL=1 才放行（本机
SMTP 中继是合法配置）；RFC1918 私网**刻意放行**——内网自建 Mattermost /
SMTP 很常见，做到那个程度会把正常部署一起废掉，这条取舍写进了测试断言。
【中】汇总消息被截断后整批标记已送达 = 静默丢失
渠道都有长度上限（企微 4096 字节最紧）。此前渲染完整篇再截断、然后整批
标记成功：被截掉的那些既不在消息里、也不在失败列表里，投递历史还显示
成功。现改为按**整条**打包，只标记真正装下的，其余回队续发，消息头部
如实写明还有多少条在下一条。被推迟的条目**不消耗重试次数**（领取时乐观
+1 的那次减回去），否则 500 条的积压会在第三段就把尾部判成失败。
【中】其余修复
- min_severity 打错字让过滤器静默失效（未知级别序数为 0 → rank>=0 恒真，
用户以为「仅高危」实际全推）。改为写入时校验取值。
- rate_per_min=0（不限流）不可达：文档/UI/令牌桶都按 0=不限流解释，唯独
写库那层 `if <=0 取默认值` 把它改成 20 或 100。默认值改到接口层填。
- digest 渠道完全绕过令牌桶（allow 被扣却没人用）。
- 失败处置按整批 max(attempts) 判断，让老投递连坐同批的新投递。
- 汇总批次里快照无法解析的投递被静默标记成功。
- url.Parse 失败时错误文本仍带完整地址（上一轮只修了 http.Client.Do 那侧；
且当时的用例全走 scheme 分支、没覆盖解析失败路径，是假保证）。
- 单渠道每轮投递条数可能超出租约时长（多实例下重复发送）。加了防漂移
断言，写的时候立刻发现原取值 6 恰好用满租约、零余量，已改 5。
- Telegram 截断可能切断 HTML 实体，导致整条被拒收。
- 邮件把 SMTP 4xx（灰名单等临时失败）判成永久失败，最该重试的场景从不重试。
- 提交嵌套结构时会把掩码字面量真的写进库，导致鉴权静默失效。
测试：notify 包从 82% 提到 86%，新增 SSRF 守卫、掩码绕过（用攻击形状的
输入而非「防御逻辑的正确输入」）、分段投递收敛、markdown 转义、SMTP 4xx/5xx
分类等回归用例；端到端补了一条「60 条长标题跨多轮发完且不卡死」的收敛测试。
Co-Authored-By: Claude Code <[email protected]>
|
2026-09-30 16:25:06 +08:00 |
|
|
luckoneandClaude Code
|
f3fb37f70d
|
feat(notify): 漏洞发现支持推送到钉钉/飞书/企业微信等六种渠道
新增「系统 → 通知推送」页，把扫描发现的漏洞推送到钉钉、飞书、企业微信、
通用 Webhook、Telegram、邮件。同一类型可配任意多个机器人实例，每个实例独立
设启停、限流与过滤规则（最低级别 / 任务资产范围 / 漏洞类型关键词 / 是否接收
处置状态变更）。推送时机分实时与汇总两种模式，「高危实时、其余汇总」建两个
渠道即可表达，策略不写死在代码里。带投递历史与失败重发。
三个关键设计：
1. 写漏洞的事务只做一次盲 INSERT。notification_events 由 RecordFindingTx
在同一事务内写入，保证「漏洞落库」与「推送任务存在」原子一致；这条 INSERT
刻意不读渠道表、不跑用户的过滤规则，否则一条配错的过滤条件就能污染甚至
中止事务，让高危漏洞存不进库。为把失败隔离在这一条语句上（PostgreSQL 中
事务内任一语句报错会让整个事务作废、连 COMMIT 都失败），它被 SAVEPOINT
包住，失败时只记日志。
2. 投递用租约领取而非长事务。FOR UPDATE SKIP LOCKED 领取后把行置为 sending、
把 next_attempt_at 推到未来作为租约，提交后再做网络投递，因此投递期间不
持有数据库锁；崩溃留下的 sending 行会被下一轮重新领取，自愈且不会无限重试。
3. 限流不消耗重试预算。先按渠道令牌桶算出本轮还能发几条，再按这个数量领取；
顺序反过来会让被限流挡下的投递白计一次尝试，三次预算被等待耗光后落入失败。
审计并修复的四个问题：
- 推送凭据经错误信息外泄：http.Client.Do 返回的 *url.Error 会把完整 URL 打进
错误文本，而钉钉 access_token、企业微信 key、飞书 hook id、Telegram
/bot<token>/ 都就在 URL 里。该串流入 last_error（明文落库）、投递历史接口
（绕过渠道掩码）、服务端日志与前端错误提示。现统一脱敏为 scheme://host
+ 底层原因，并拒绝跨主机重定向。
- 最低级别门槛打错字会让过滤器静默失效：未知级别序数为 0，判定退化成
rank >= 0 恒真，用户以为限制「仅高危」实际全推。现于写入路径校验取值。
- 汇总批次无上限：一次领取把全部待发行读进内存、消息被渠道长度上限截掉大半
且静默丢失。现单批上限 500 条，超出部分留库成为下一批。
- 邮件渠道把 SMTP 4xx（灰名单等临时失败）判成永久失败，导致这类最该重试的
场景从不重试。现按应答码首位区分 4xx/5xx。
测试：notify 包 82% 覆盖（含用自建最小 SMTP 服务器驱动的完整邮件协议会话、
两种签名算法对 OpenSSL 基准值的比对、UTF-8 边界截断、以及模板能力边界的
反射断言）；db 与 server 侧共 29 个用例跑真实 PostgreSQL，其中端到端用例
真发 HTTP 到假接收端并断言消息内容与投递状态。
Co-Authored-By: Claude Code <[email protected]>
|
2026-09-30 16:25:06 +08:00 |
|
|
luckoneandClaude Code
|
18589b270e
|
fix(db): 修正公司 ICP 归属用例连接关闭顺序导致的资产残留
清理注册在 t.Cleanup 里，而连接关闭用的是 defer d.Close()。defer 在函数
返回时先执行、t.Cleanup 在其后，于是两条 DELETE 全部落在**已关闭的连接**
上，错误又被 `_, _ =` 丢弃，测试资产与公司因此永久残留在库里。
该用例用 MAX(companies.id)+1 当假 TaskID 给资产打标。残留本身不会立刻报错，
但一旦这个数字与其他用例的任务 id 相撞，那个按「恰好 N 个资产」断言的用例
就会失败，而现象（某个无关测试的资产计数不对）与原因（另一个测试的连接
关闭顺序）相距极远，排查成本很高。
改为关闭连接也走 t.Cleanup 并注册在清理之前（t.Cleanup 后进先出，保证清理
先跑），同时让清理失败显式报错而不是被吞掉。
注：同一模式（defer d.Close() + 在 t.Cleanup 里写库）在 db 包另有十余处，
本次只修被实证触发的那一处。
Co-Authored-By: Claude Code <[email protected]>
|
2026-09-30 16:24:47 +08:00 |
|