直接用gin.context.request.url.rawquery会漏掉post body，因rawquery仅含query string而不含body，导致签名与实际请求体不一致，攻击者可篡改body绕过校验。

为什么直接用 gin.Context.Request.URL.RawQuery 会漏掉 POST body？

防篡改校验本质是签名验证，但很多人只对 URL 参数签名，忽略 POST、PUT 请求体。Gin 的 c.Request.URL.RawQuery 只含 query string，不包含 body 内容，导致签名和实际请求体不一致——攻击者可随意修改 body 而签名仍通过。

• GET 请求：签名应覆盖 RawQuery + method + path
• POST/PUT 等：必须读取并参与签名的 body，且只能读一次（Request.Body 是单次流）
• 正确做法：在中间件中用 c.Request.Body 读取原始字节，再用 bytes.NewReader 重置给后续 handler 使用

如何安全读取并复用 Request.Body？

Gin 默认不缓存 body，一旦 c.ShouldBindJSON() 或 c.PostForm() 调用，原始 body 就不可再读。防篡改中间件必须在绑定前完成签名计算，并把 body “还回去”。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 调用 io.ReadAll(c.Request.Body) 获取原始字节
• 立即用 c.Request.Body = io.NopCloser(bytes.NewReader(bodyBytes)) 恢复可读状态
• 注意：不能用 strings.NewReader，因为 bytes.NewReader 实现了 io.ReadSeeker，部分 Gin 内部逻辑依赖 seek 能力
• 若已启用 gin.Recovery() 或其他中间件提前读过 body，需确保防篡改中间件排在最前

HMAC-SHA256 签名字符串拼接顺序怎么定？

签名字符串顺序不统一，会导致客户端和服务端计算结果不一致。推荐固定格式：method|path|query|body_hash，其中 body_hash 是 body 的 sha256 哈希（避免直接拼接大 body 影响性能和长度）。

• method 全大写：如 "POST"
• path 不带 query：用 c.Request.URL.Path，不是 RawPath
• query 用 c.Request.URL.RawQuery（保留原始编码，不 decode）
• body hash 统一用 hex.EncodeToString(sha256.Sum256(bodyBytes).Sum(nil))
• 密钥必须服务端存储，禁止硬编码；建议从环境变量或 secret manager 加载

如何验证 X-Signature 头并拦截非法请求？

签名头通常叫 X-Signature 或 Authorization，需提取后与服务端计算值比对。直接用 == 比较有时间侧信道风险，应使用 subtle.ConstantTimeCompare。

• 从 c.GetHeader("X-Signature") 取值，空或长度不符直接 c.AbortWithStatus(401)
• 用 base64.StdEncoding.DecodeString 解码签名，失败则拒绝
• 计算服务端签名后，用 subtle.ConstantTimeCompare([]byte(expected), []byte(got)) == 1 判等
• 校验失败时，不要返回具体原因（比如“签名错误” vs “过期”），统一返回 401，避免信息泄露

签名逻辑本身不复杂，但 body 复用、哈希时机、常量时间比较这些细节，任何一个出错都会让整个防篡改形同虚设。尤其注意中间件执行顺序和 Request.Body 的生命周期——它不像变量，读完就没了。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！