Go DoS/Resource Exhaustion Vulnerability Patterns (CWE-400/770/476)

当审计 Go 代码中涉及 goroutine 管理、channel 操作、HTTP 请求处理、资源分配、panic 恢复时加载此 Skill。

Detection Strategy

Sources（攻击入口）： - HTTP 请求 body（大 payload、大量并发请求） - gRPC 消息（protobuf 嵌套深度、repeated 字段大小） - WebSocket 帧（无限制的消息大小/频率） - P2P 网络消息（如 go-ethereum 的 peer message） - 用户控制的分配大小参数

Sinks（资源消耗点）： - go func() -- 无限制的 goroutine 创建 - make([]byte, userSize) / make([]T, userSize) -- 用户控制的内存分配 - io.ReadAll(r) / ioutil.ReadAll(r) -- 读取整个 body 到内存 - json.NewDecoder(r).Decode(&v) -- 无大小限制的 JSON 解码 - yaml.Unmarshal(data, &v) -- YAML 解码（支持 anchor/alias 指数扩展） - proto.Unmarshal(data, msg) -- protobuf 解码无嵌套限制 - panic() 在 HTTP handler 中未被 recover() 捕获 - Channel 操作（ch <- v 阻塞、<-ch 永久等待）

Sanitization（资源限制屏障）： - io.LimitReader(r, maxSize) -- 限制读取大小 - http.MaxBytesReader(w, r.Body, maxSize) -- HTTP body 大小限制 - context.WithTimeout / context.WithDeadline -- 超时控制 - Goroutine pool（worker pattern, semaphore.Weighted） - recover() 在 goroutine 入口 - Rate limiting 中间件（golang.org/x/time/rate） - Channel 缓冲区大小限制 + select with default

检测路径：

# Goroutine 创建
grep -rn "go func|go .*(" --include="*.go"
# 无限制读取
grep -rn "io.ReadAll|ioutil.ReadAll|io.Copy" --include="*.go"
# 内存分配
grep -rn "make([]byte|make([]" --include="*.go"
# Panic/Recover
grep -rn "panic(|recover()" --include="*.go"
# JSON/YAML/Protobuf 解码
grep -rn "json.NewDecoder|json.Unmarshal|yaml.Unmarshal|proto.Unmarshal" --include="*.go"
# 资源限制
grep -rn "LimitReader|MaxBytesReader|context.WithTimeout" --include="*.go"
# Channel 操作
grep -rn "make(chan|<-.*chan" --include="*.go"

1. 搜索资源消耗点（goroutine 创建、内存分配、IO 读取、解码操作）
2. 追踪输入来源，确认是否来自不可信外部输入
3. 验证是否有资源限制：
4. io.ReadAll 之前是否有 LimitReader/MaxBytesReader？
5. Goroutine 是否有退出条件（context cancellation、done channel）？
6. make([]T, size) 的 size 是否有上限检查？
7. HTTP handler 是否有 recover() 中间件防止 panic 导致进程崩溃？
8. JSON/protobuf 解码是否限制了嵌套深度或大小？
9. 若无资源限制 -> 标记为候选漏洞

Detection Checklist

• [ ] Goroutine 泄漏审计 (CWE-400)：go func() 内部是否有退出条件？是否监听 ctx.Done() 或 done channel？无退出条件的 goroutine 在请求取消后仍会占用资源。
• [ ] io.ReadAll 无限制审计 (CWE-770)：是否直接 io.ReadAll(r.Body) 而未使用 http.MaxBytesReader 或 io.LimitReader 限制？攻击者可发送超大 body 导致 OOM。
• [ ] make([]byte, size) 分配审计 (CWE-789)：size 是否来自用户输入？是否有上限检查？直接 make([]byte, userSize) 可用于 OOM 攻击。
• [ ] HTTP Handler Panic 恢复审计 (CWE-476)：注意 Go 标准库 net/http 的 Server 内置了 per-request recover()，单个 handler panic 不会导致进程崩溃（但会关闭该连接）。第三方框架（如 gin/echo）通常也有内置 recovery 中间件。真正危险的是在 handler 中启动的 子 goroutine 中 panic（不受 HTTP server recover 保护）。对于不安全的类型断言（如 data["key"].(string)），应使用 comma-ok 模式 v, ok := data["key"].(string) 避免 panic。
• [ ] Channel 死锁审计 (CWE-400)：无缓冲 channel（make(chan T)）在发送端/接收端缺失时是否会永久阻塞？select 是否包含 default 或 timeout 分支？
• [ ] JSON/YAML/Protobuf 大小限制审计 (CWE-770)：json.NewDecoder(r).Decode() 是否限制了输入大小？YAML 的 anchor/alias 是否允许指数级扩展（"billion laughs"）？Protobuf 嵌套深度是否有限制？
• [ ] HTTP/2 流滥用审计 (CWE-400)：Go HTTP/2 server 是否配置了 MaxConcurrentStreams？是否容易受到 rapid reset 攻击（CVE-2023-44487）？
• [ ] 自引用/循环引用审计 (CWE-400)：etcd gateway 风格的配置中，服务是否可能将自身作为后端端点，形成无限循环？DNS 或服务发现是否可能形成环路？
• [ ] WebSocket 消息限制审计 (CWE-770)：WebSocket 连接是否配置了 SetReadLimit？是否有消息频率限制？

False Positive Exclusion Guide

以下模式不是此类漏洞： - go func() 在 init() 中启动的后台 worker -- 生命周期与进程相同，不会泄漏 - io.ReadAll 读取小文件或内部配置 -- 来源可信且大小可控 - panic 用于编程错误检测 -- 如 panic("unreachable") 在 switch default 中 - 带 context.WithTimeout 的 goroutine -- 有超时退出机制

以下模式需要深入检查： - go func() 在 HTTP handler 中 -- 每个请求创建 goroutine 且无 pool 限制 - json.Decoder 在 API endpoint -- 未设置 MaxBytesReader 的 HTTP handler - recover() 在 goroutine 内但不在 HTTP handler 链 -- 可能只保护了子 goroutine 但 handler 本身可 panic - select {} 永久阻塞 -- 在某些情况下是有意设计，但也可能是 bug

Real-World Cases

详见 references/cases.md（7 个真实案例，需要时加载）。