摘要：# 业务接口被恶意频繁调用？这套防重放机制，我劝你早点安排上 前两天，一个做电商的朋友半夜给我打电话，声音都带着火气：“我们那个优惠券领取接口，被人用脚本刷了快一万张！这玩意儿不是有验证码吗？怎么防不住？” 我让他把日志发过来一看，好家伙，请求头、参数…

业务接口被恶意频繁调用？这套防重放机制，我劝你早点安排上

前两天，一个做电商的朋友半夜给我打电话，声音都带着火气：“我们那个优惠券领取接口，被人用脚本刷了快一万张！这玩意儿不是有验证码吗？怎么防不住？”

我让他把日志发过来一看，好家伙，请求头、参数、时间戳，全都整整齐齐，一看就是专业选手。验证码？人家早就用打码平台绕过去了。这就是典型的重放攻击——攻击者根本不需要破解你的加密算法，他只需要像复读机一样，把你之前一次合法的请求，原封不动地再发一遍、十遍、一百遍。

说白了，你的接口在攻击者眼里，就是个自助提款机。他拿到一张合法的“票”（即一次完整的请求数据），就能无限次取钱。

这种问题，我见过太多了。很多团队一上来就想着上高防IP、买WAF，钱花了不少，但针对这种“合法格式的非法重复请求”，往往一拳打在棉花上。真正的防线，得从业务逻辑本身的设计入手。

今天，我就抛开那些云里雾里的安全黑话，跟你聊聊怎么从零开始，设计一套能落地、能扛事的接口防重放机制。咱们不搞“五步法”、“八原则”那种教科书罗列，就讲几个核心的、你今晚就能琢磨起来的思路。

防重放，到底在防什么？

首先得统一思想。防重放机制的核心目标就一个：确保同一个请求（或者说，同一笔交易意图）只能被成功执行一次。

攻击者能重放，是因为他抓住了你系统的两个“信任”：

1. 系统无法区分“请求”和“请求的复制体”。只要数据包长得一样，你就认为是同一个人来的新请求。
2. 系统没有记录或校验请求的“唯一性标识”。或者说，你用的标识（比如单纯的时间戳）太容易被预测或伪造。

所以，我们的设计思路就得反着来：给每个合法的请求都打上一个一次性、不可预测、难以伪造的“数字水印”，并且让服务器牢牢记住哪些水印已经用过了。下次再看到同样的水印，直接拒绝。

道理就这么简单，但魔鬼全在细节里。

核心武器：Nonce与时间戳的“双保险”

这是最经典、也最有效的组合拳，但很多人其实没配好。

• Nonce（随机数）：它的唯一使命就是“只用一次”。每次客户端发起请求（比如提交订单），都必须生成一个全新的、全局唯一的随机字符串，放在请求参数或Header里（比如 X-Nonce: a1b2c3d4e5）。服务器端收到后，先去缓存（比如Redis）里查这个Nonce是否存在。如果存在，说明是重放，直接驳回；如果不存在，就把这个Nonce存起来，并设置一个合理的过期时间（比如5分钟），然后才处理业务逻辑。

  • 关键点：这个随机数必须够随机（用安全的随机数生成器），长度足够（比如16位以上），防止被爆破猜测。我见过有人用“用户ID+递增数字”当Nonce，这基本等于没设防。

• 时间戳：光有Nonce还不够，因为恶意请求可能会延迟很久才重放（比如一个月后）。我们得给请求加上“保质期”。客户端需要在请求里带上当前的时间戳（比如 X-Timestamp: 1698301234）。服务器收到后，检查这个时间戳与服务器当前时间的差值。如果超过一个你设定的合理窗口（比如5分钟），就直接拒绝，连后面的业务逻辑都别走了。

  • 关键点：这个“时间窗口”是关键。设太短（如10秒），网络稍有波动正常用户就失败了；设太长（如1小时），攻击者就有充足的时间窗口作恶。根据你的业务容忍度来，5-15分钟是常见范围。 另外，务必注意服务器之间的时间同步（用NTP），别自己人打自己人。

这两个必须一起用！ 时间戳防“旧票新用”，Nonce防“一票多用”。少了任何一个，都有漏洞。

进阶玩法：给请求签个名

如果你的系统对安全性要求更高（比如涉及支付、核心资产操作），那么“Nonce+时间戳”还是裸奔在HTTP里，可能被中间人截获和篡改。这时候，你需要引入签名机制。

简单说，就是客户端在发起请求前，把所有的关键参数（包括Nonce、时间戳、业务参数等）按照固定规则拼接成一个字符串，然后用一个只有你和服务器知道的密钥（比如从服务端动态下发的Token），通过HMAC-SHA256这类算法生成一个签名（Signature），放在请求头里。

服务器收到后，用同样的规则和密钥自己再算一遍签名。如果对不上，说明请求参数在传输中被篡改了，直接拒绝。

这个签名的妙处在于：即使攻击者截获了你的整个请求包，他也无法修改其中的任何一个参数（比如把转账金额从1元改成10000元），因为一旦修改，签名就对不上了，服务器不认。这同时也就防了重放，因为重放的请求必须原封不动，而原封不动的请求里的时间戳很可能已经过期了。

# 一个简化的签名流程示例（伪代码）
1. 客户端准备参数：nonce=abc123, timestamp=1698301234, amount=100, userId=888
2. 按规则拼接：`nonce=abc123×tamp=1698301234&amount=100&userId=888`
3. 用密钥 `secret_key` 计算HMAC-SHA256签名：`sign = hmac_sha256(secret_key, 拼接字符串)`
4. 发送请求，Header中携带：X-Nonce, X-Timestamp, X-Signature
5. 服务端依样画葫芦计算签名，比对X-Signature。同时校验nonce唯一性和时间戳有效性。

这套组合拳下来，重放攻击的成本就非常高了。

别忘了这些“接地气”的细节

方案设计得再漂亮，落地时掉坑里才最要命。分享几个我踩过或看别人踩过的坑：

1. Nonce存储别用数据库：频繁的查库和插入，在高并发下是性能灾难。直接用Redis，SET key nonce EX 300 NX（设置5分钟过期，且仅当key不存在时设置成功），原子操作，性能极高，还能天然防并发重复提交。
2. 时间窗口要留有余量：考虑到用户手机/电脑时间可能不准，以及网络延迟，可以在服务端校验时，允许时间戳有少量前后漂移（比如±30秒）。这叫“宽容但不纵容”。
3. 对“异常”保持敏感：监控同一个Nonce的重复提交频率、同一个IP/用户短时间内触发时间戳过期的频率。这些异常模式本身就是攻击信号，可以自动触发告警甚至临时封禁。
4. 核心业务，强制上签名：像登录、注册、支付、修改密码这类接口，别犹豫，必须上签名。普通的查询列表接口，可以视情况只用“Nonce+时间戳”甚至更宽松的策略。安全本质上是一种成本和风险的平衡。
5. 密钥管理是命门：签名用的密钥，绝对不能硬编码在客户端！要通过安全的通道（如HTTPS下的登录接口）动态下发，并且定期更新。客户端最好有自动刷新密钥的机制。

最后说句大实话

没有任何一种安全方案是银弹。防重放机制是构建你业务安全底座的重要一环，但它主要防的是“懒”攻击和初级攻击者。面对有组织的、持续性的攻击（比如结合了海量代理IP、模拟正常用户行为的高级爬虫），你还需要在更上层布防，比如引入更复杂的行为验证（不是简单滑动拼图）、业务风控系统（实时分析用户行为序列）、甚至对可疑流量进行二次验证。

但话说回来，连最基础的防重放都没做，就相当于你家大门虚掩，却整天担心小偷会开锁——想多了，人家直接推门就进了。

先从把“Nonce+时间戳”这套组合拳打扎实开始吧。代码量不大，但效果立竿见影。你的业务接口，值得拥有这份“安心”。