ARTEX

773 Commits 112 Branches 4 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
BaaRai	e233c02314	Translate all Chinese text to English Comments, doc comments, UI labels, log and error messages, LLM prompt strings, markdown docs, test data and assertions. Identifiers, enum keys, routes, placeholders and code structure are unchanged. Notes: - docs/漏洞流量证据.md renamed to docs/vulnerability-traffic-evidence.md - tests that exercised CJK specific handling (GBK zip names, Chinese full text search) now use ASCII equivalents; go build passes and the test suite matches the pre translation baseline (remaining failures need a PostgreSQL DSN and fail identically on the original) - frontend mention syntax now uses English kinds (finding, asset, ...) matching the backend, chat mentions tests pass	2026-10-08 23:14:34 +02:00
luckoneandClaude Code	765c0e99e3	fix(notify): 安全审计修复 —— 掩码绕过、SSRF、静默丢失等 12 项对推送功能做了一轮安全审计，每条都先复现、再修、再补回归测试。以下按严重程度排列。【严重】掩码可被「改目标地址、保留凭据」绕过目标地址与凭据是两套独立字段，而配置合并对「未提及的键」保留原值。于是只改地址、对凭据避而不谈，服务端就会把库里的真凭据发到任意地址。已实测复现四个渠道：通用 Webhook 的 Authorization 头、Telegram 的 Bot Token （进请求路径）、邮件的 SMTP 密码（STARTTLS 后交给对端）、钉钉/飞书的加签密钥（该项不可利用，一并列出仅为说明面）。完全静默、不依赖重定向，所以上一轮加的「拒绝跨主机跳转」挡不住它。修法：新增 Channel.DestinationKeys() 声明「消息发往哪」，PrepareConfigUpdate 在地址变化时要求对每一个凭据字段显式表态（给新值，或显式留空表示不再需要）——原样回传掩码值等于「沿用旧凭据」，正是攻击形状，一并拒绝。刻意不做「自动丢弃凭据」：对可选字段（如 headers）那会变成「鉴权静默没了但接口返回成功」，比报错更难排查。【中】markdown 系三渠道对不可信内容零转义钉钉/企微/飞书此前完全不转义（Telegram 与邮件都做了），而标题与摘要来自模型输出、资产 url 来自被测目标。一条标题里的 `[文字](http://evil)` 会在工程师的钉钉里变成可点击外链；`![](http://evil/beacon)` 会被客户端拉取，泄露阅读者 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 <noreply@anthropic.com>	2026-09-30 16:25:06 +08:00
luckoneandClaude Code	4eb5311998	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 <noreply@anthropic.com>	2026-09-30 16:25:06 +08:00

Author

SHA1

Message

Date

BaaRai

e233c02314

Translate all Chinese text to English

Comments, doc comments, UI labels, log and error messages, LLM prompt
strings, markdown docs, test data and assertions. Identifiers, enum
keys, routes, placeholders and code structure are unchanged.

Notes:
- docs/漏洞流量证据.md renamed to docs/vulnerability-traffic-evidence.md
- tests that exercised CJK specific handling (GBK zip names, Chinese
  full text search) now use ASCII equivalents; go build passes and the
  test suite matches the pre translation baseline (remaining failures
  need a PostgreSQL DSN and fail identically on the original)
- frontend mention syntax now uses English kinds (finding, asset, ...)
  matching the backend, chat mentions tests pass

2026-10-08 23:14:34 +02:00

luckoneandClaude Code

765c0e99e3

fix(notify): 安全审计修复 —— 掩码绕过、SSRF、静默丢失等 12 项

对推送功能做了一轮安全审计，每条都先复现、再修、再补回归测试。
以下按严重程度排列。

【严重】掩码可被「改目标地址、保留凭据」绕过
目标地址与凭据是两套独立字段，而配置合并对「未提及的键」保留原值。于是
只改地址、对凭据避而不谈，服务端就会把库里的真凭据发到任意地址。已实测
复现四个渠道：通用 Webhook 的 Authorization 头、Telegram 的 Bot Token
（进请求路径）、邮件的 SMTP 密码（STARTTLS 后交给对端）、钉钉/飞书的加签
密钥（该项不可利用，一并列出仅为说明面）。完全静默、不依赖重定向，所以
上一轮加的「拒绝跨主机跳转」挡不住它。

修法：新增 Channel.DestinationKeys() 声明「消息发往哪」，PrepareConfigUpdate
在地址变化时要求对**每一个**凭据字段显式表态（给新值，或显式留空表示不再
需要）——原样回传掩码值等于「沿用旧凭据」，正是攻击形状，一并拒绝。
刻意不做「自动丢弃凭据」：对可选字段（如 headers）那会变成「鉴权静默没了
但接口返回成功」，比报错更难排查。

【中】markdown 系三渠道对不可信内容零转义
钉钉/企微/飞书此前完全不转义（Telegram 与邮件都做了），而标题与摘要来自
模型输出、资产 url 来自被测目标。一条标题里的 `[文字](http://evil)` 会在
工程师的钉钉里变成可点击外链；`![](http://evil/beacon)` 会被客户端拉取，
泄露阅读者 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 <noreply@anthropic.com>

2026-09-30 16:25:06 +08:00

luckoneandClaude Code

4eb5311998

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 <noreply@anthropic.com>

2026-09-30 16:25:06 +08:00