dvcrn 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 缓冲区大小限制 +
selectwithdefault
检测路径：
# 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"
- 搜索资源消耗点（goroutine 创建、内存分配、IO 读取、解码操作）
- 追踪输入来源，确认是否来自不可信外部输入
- 验证是否有资源限制：
io.ReadAll之前是否有LimitReader/MaxBytesReader？- Goroutine 是否有退出条件（context cancellation、done channel）？
make([]T, size)的 size 是否有上限检查？- HTTP handler 是否有
recover()中间件防止 panic 导致进程崩溃？ - JSON/protobuf 解码是否限制了嵌套深度或大小？
- 若无资源限制 -> 标记为候选漏洞
Detection Checklist
- Goroutine 泄漏审计 (CWE-400)：
go func()内部是否有退出条件？是否监听ctx.Done()或donechannel？无退出条件的 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-requestrecover()，单个 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 handlerrecover()在 goroutine 内但不在 HTTP handler 链 -- 可能只保护了子 goroutine 但 handler 本身可 panicselect {}永久阻塞 -- 在某些情况下是有意设计，但也可能是 bug
Real-World Cases
详见 references/cases.md（7 个真实案例，需要时加载）。