如何在 Go 中实现对 API 接口的防重放攻击

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《如何在 Go 中实现对 API 接口的防重放攻击》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

仅靠时间戳无法防御重放攻击，因签名和时间戳在有效期内（如±180秒）时，服务端无法区分新请求与截获的旧请求；必须结合唯一nonce和服务端原子性去重校验，确保同一nonce绝不被接受第二次，且nonce须绑定用户维度并严格管理生命周期。

只校验时间戳是无效防御，必须绑定 nonce + 服务端状态去重，否则攻击者在有效窗口内重放一次就成功了。

为什么不能只用 time.Now().Sub(req.Timestamp) 判断

重放攻击不是“接口被调用多次”，而是“合法签名的旧请求被截获后再次提交”。只要签名和时间戳仍在有效期（比如 ±180 秒），服务端就无法区分这是新请求还是重放包。关键缺失的是「请求唯一性」验证——同一个 nonce 绝对不能被接受第二次。

• 仅靠时间戳，时钟偏差、网络抖动、服务处理延迟都会导致误判或漏判
• nonce 必须与用户/设备维度强绑定，例如拼成 "nonce:uid_123:abc456"，不能全局共用
• 服务端必须原子性地完成「检查是否已存在 + 写入新记录」，否则并发下会出竞态

用 Redis 实现原子 nonce 校验（推荐生产方案）

这是目前最常用、性能与安全平衡最好的做法。核心是利用 Redis 的 SET key value EX 300 NX 命令：NX 确保只在 key 不存在时写入，EX 自动过期，整个操作是原子的。

• key 示例："nonce:user_789:fa2b3c"（user_789 来自 token 解析，fa2b3c 是客户端传的 X-Nonce）
• TTL 设为 300 秒（5 分钟），需 ≥ 最大网络延迟 + 服务处理耗时，但不超过业务允许的时钟偏差
• 不要先 GET 再 SET：中间有毫秒级窗口，高并发下必然撞出重放
• 错误处理要区分：redis.ErrNil 表示已存在（重放），其他 err 才是连接或命令异常

没有 Redis 时的本地内存 fallback 方案

适用于单机部署、QPS 较低、能接受极小概率漏判的内部工具类 API。本质是维护一个带时间戳的滑动窗口 map[string]time.Time，配合定时清理。

• 必须用 sync.RWMutex 手动加锁，sync.Map 不支持按值删除，无法做 TTL 清理
• 清理 goroutine 要每 30–60 秒扫描一次，删掉 time.Since(t) > window 的项（window 通常设为 300 秒）
• 查 nonce 时先读锁取时间，再判断是否超时；写入时写锁插入新项
• 该方案无法跨进程共享状态，多实例部署时必须换 Redis 或分布式缓存

客户端签名里必须包含什么字段

服务端防重放能力再强，客户端不配合也白搭。签名原文中至少要明文携带以下两项，且都参与 HMAC-SHA256 计算：

• timestamp：必须是毫秒级，用 time.Now().UnixMilli()，不能只用秒级
• nonce：16 字节随机数，用 crypto/rand.Read() 生成，转 hex 或 base64 后传给服务端

这两项不能只塞进签名原文里不暴露——服务端需要单独提取它们做时效性和去重校验。硬编码 nonce、复用 timestamp、或把它们藏在加密体里不透出，都会让防重放逻辑失效。

真正难的不是写完校验逻辑，而是确保 nonce 的生命周期管理不出错：过期时间设太短会误杀正常请求，设太长会拖慢 Redis 内存回收；key 的命名空间漏了用户标识，就会让不同用户的 nonce 相互干扰；客户端没按规范生成随机串，整个机制就形同虚设。

理论要掌握，实操不能落！以上关于《如何在 Go 中实现对 API 接口的防重放攻击》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！