mirror of
https://github.com/RuoJi6/ARTEX.git
synced 2026-10-27 17:03:49 +08:00
luckoneandClaude Code
f3fb37f70d
新增「系统 → 通知推送」页，把扫描发现的漏洞推送到钉钉、飞书、企业微信、 通用 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]>
76 lines
2.8 KiB
Go
76 lines
2.8 KiB
Go
package notify
|
|
|
|
import (
|
|
"context"
|
|
"encoding/json"
|
|
"errors"
|
|
"fmt"
|
|
)
|
|
|
|
// weComMarkdownLimit 是企微群机器人 markdown content 的硬上限（字节，非字符）。
|
|
// 这是全部六个渠道里最紧的限制，也是 TruncateBytes 存在的主要原因。
|
|
const weComMarkdownLimit = 4096
|
|
|
|
// weComChannel 实现企业微信群机器人。
|
|
//
|
|
// 平台特性：
|
|
// - 唯一通过 URL 上的 key 鉴权，不支持加签——所以 webhook 地址本身就是全部凭据。
|
|
// - markdown content 上限 4096 **字节**，超长整条被拒（不是截断）。中文 3 字节/字，
|
|
// 意味着正文只有一千多字可写，必须客户端截断。
|
|
// - 限流 20 条/分钟，同样靠客户端限流兜住。
|
|
type weComChannel struct{}
|
|
|
|
func (weComChannel) Kind() string { return KindWeCom }
|
|
|
|
func (weComChannel) DefaultRatePerMin() int { return 20 }
|
|
|
|
// 企业微信只有 Webhook 一处凭据（URL 上的 key），且它不支持加签——
|
|
// 整个地址就是全部凭据，没有别的字段需要掩码。
|
|
func (weComChannel) SecretKeys() []string { return []string{"webhook"} }
|
|
|
|
func (weComChannel) Validate(cfg map[string]any) error {
|
|
hook := cfgString(cfg, "webhook")
|
|
if hook == "" {
|
|
return errors.New("缺少 Webhook 地址")
|
|
}
|
|
if err := validateHTTPURL(hook); err != nil {
|
|
return fmt.Errorf("Webhook 地址无效: %w", err)
|
|
}
|
|
return nil
|
|
}
|
|
|
|
func (c weComChannel) Send(ctx context.Context, cfg map[string]any, m Message) error {
|
|
if err := c.Validate(cfg); err != nil {
|
|
return Permanent(err)
|
|
}
|
|
// 汇总批可能很长（50 条 × 每条一行 + 前缀），4096 字节很容易超。
|
|
// 截断在这里做而不是靠平台报错：被拒意味着这一批全丢，而截断至少送达前若干条。
|
|
content := markdownBody(m, weComMarkdownLimit)
|
|
payload := map[string]any{
|
|
"msgtype": "markdown",
|
|
"markdown": map[string]any{"content": content},
|
|
}
|
|
raw, err := doJSON(ctx, "POST", cfgString(cfg, "webhook"), nil, payload)
|
|
if err != nil {
|
|
return err
|
|
}
|
|
var res struct {
|
|
ErrCode int `json:"errcode"`
|
|
ErrMsg string `json:"errmsg"`
|
|
}
|
|
if err := json.Unmarshal(raw, &res); err != nil {
|
|
return fmt.Errorf("解析企业微信响应失败: %w (%s)", err, snippet(raw))
|
|
}
|
|
if res.ErrCode != 0 {
|
|
// 45009 是接口调用超过限制——平台的限流窗口会滚动，退避后重试是有效的，
|
|
// 所以显式归为可重试。走到这里说明客户端 rate_per_min 配得过于激进，
|
|
// 重试只是兜底，真正的修法是调低该渠道的限流值。
|
|
if res.ErrCode == 45009 {
|
|
return fmt.Errorf("企业微信限流 %d: %s", res.ErrCode, res.ErrMsg)
|
|
}
|
|
// 93000 是 webhook key 无效——永久失败，重试不会自愈。
|
|
return Permanent(fmt.Errorf("企业微信返回错误 %d: %s", res.ErrCode, res.ErrMsg))
|
|
}
|
|
return nil
|
|
}
|