Zipkin HTTP 收集器经过 gzip 压缩的跨度可能耗尽 JVM 堆内存

技术细节

• 触发形状: 通过 POST 一个有效的 Zipkin v2 JSON 扩展列表到 /api/v2/spans, 并设置 Content-Encoding: gzip 来扩展解压大小。
• 根本原因摘要: 收集器解压并解析完整的扩展列表, 但没有有效的默认限制, 以控制解压大小、扩展数量或 gzip 比率。
• 利用条件: HTTP 收集器可以匿名访问, gzip 允许, 且在 Zipkin 解码体之前, 解压大小/扩展数量不受限制。
• 静态源: External POST /api/v2/spans 或 /api/v1/spans 体, 可选 Content-Encoding: gzip
• 静态汇聚: ZipkinHttpCollector.validateAndStoreSpans 聚合请求, UnzippingBytesRequestConverter 解码 gzip, Collector.acceptSpans 解码 List<Span>

建议的补救措施

• 在易受攻击的入口处添加请求体大小、对象数量、主题/作业/关键字数量、队列长度、活动线程数或聚合保留字节的硬限制。
• 在执行昂贵的体读取、解压、JSON/Protobuf 解析、图像渲染、任务创建或状态保留之前, 强制验证身份和配额检查。
• 为匿名或低权限的入口添加每个 IP、每个用户、每个令牌或每个客户端的速率和资源配额。
• 尽可能早地返回 400/413/429, 并在拒绝后避免保留完整的请求体、负载或不完整的协议状态。