单纯加时间戳不能防重放，因攻击者可篡改时间戳重发；需配合nonce实现唯一性校验，服务端须存储并检查nonce是否已使用，且与时间戳窗口一致。
为什么单纯加时间戳不能防重放
时间戳只是校验请求是否“过期”，但攻击者截获一次合法请求后，把里面的时间戳改成当前时间再重发，照样能过校验。关键缺了唯一性约束——同一时间戳下，请求必须只能被接受一次。
（一次性随机数）就是干这个的：服务端收到带
的请求，先查缓存/数据库有没有见过它，有就直接拒绝。
如何生成和验证
才不踩坑
常见错误是用
当
，看似唯一，但没做存储校验或过期清理，等于白搭。正确做法要闭环：
建议用加密安全随机数，比如
，避免可预测性
服务端必须持久化记录已用
，推荐 Redis（带 TTL）或内存缓存（如
配
）
过期时间建议设为略大于最大允许时钟偏差（比如 5 分钟），且必须和时间戳窗口一致，否则会出现“
还活着但时间戳已失效”的逻辑断层
不要在日志里明文打印
或签名原文，防止密钥泄露链路被绕过
签名时参数顺序和编码细节决定成败
签名算错，90% 出在拼接字符串的格式上。C# 默认
，但前端 JS 可能用
或
，导致同样参数签名不一致。必须统一约定：
C知道
CSDN推出的一款AI技术问答工具
下载
签名原文按固定字段顺序拼接：
+
+
+
+
（如有）——注意全部小写、无空格、无换行
推荐用
的十六进制小写字符串（非 Base64），避免 body 编码差异影响
密钥必须用
，别用
，否则中文或特殊字符会截断
签名结果转成十六进制小写字符串（
），别用 Base64，兼容性差且易出错
ASP.NET Core 中间件里怎么安全拦截并校验
别在 Controller 里做签名校验——body 可能已被读取一次，再次读取会失败。必须用中间件提前捕获原始流：
调用
允许多次读取 body
用
、
、
提取签名三要素
校验时间戳是否在窗口内（比如
秒就拒）
查
是否已存在；若通过，立刻存入缓存并设 TTL，防止并发重复提交漏判
重新读取
计算
，再拼接签名原文、用密钥计算 HMAC，比对
校验失败统一返回
，**不要暴露具体失败原因**（比如不说“nonce 已使用”，只说“签名无效”）
最常被忽略的是 body 流的 rewind 和 encoding 一致性：本地测试用 Postman 没问题，上线后前端用 axios 发送 JSON，body 自动带 BOM 或换行，签名就对不上。建议在中间件开头加一行日志输出
的实际值，出问题时能快速定位是前端传错了，还是服务端读取方式不对。
NoncenoncenonceGuid.NewGuid().ToString()noncenonceConvert.ToBase64String(RandomNumberGenerator.GetBytes(16))nonceMemoryCacheSlidingExpirationnoncenonceHMACSHA256Encoding.UTF8encodeURIencodeURIComponenttimestampnoncemethodpathbodyHashbodyHashSHA256(bodyBytes)Encoding.UTF8.GetBytes("your-secret-key")ASCIIEncodingBitConverter.ToString(bytes).Replace("-", "").ToLower()context.Request.EnableBuffering()context.Request.Headers["X-Signature"]["X-Timestamp"]["X-Nonce"]Math.Abs(now - timestamp) > 300nonceRequest.BodybodyHashX-SignatureStatus401UnauthorizedbodyHash