时间戳加随机数防重放攻击教程

本文深入剖析了PHP接口防重放攻击中仅校验timestamp和nonce的致命缺陷——因二者未与业务参数通过HMAC-SHA256签名强绑定，攻击者可在时间窗口内截包重发绕过Redis去重；强调必须对字典序排序、URL编码后的完整参数（含timestamp、nonce及所有业务字段）进行原子化签名验签，并严格遵循Redis原子写入（SET ... NX EX）、密钥安全加载、时间单位统一、多环境一致性等关键实践，直击90%开发者在调试和上线时极易忽略的底层细节，真正构建可信、健壮、可落地的防重放防线。

单纯传 timestamp 和 nonce 并在服务端做“是否见过这个 nonce”判断，根本防不住重放——攻击者截一次包，立刻重发，只要时间还在窗口内、nonce 还没被你存进 Redis，就直接过检。

为什么只校验 timestamp 和 nonce 会失效

常见错误是把防重放想成“两个字段校验”，但漏掉了最关键的绑定关系：时间戳和随机数必须被签名“锁死”在业务参数里，否则它们就是裸奔的字符串。

• 客户端可任意构造 timestamp=1714465200（2026-04-30 16:20:00）和 nonce=abc123，服务端若只查 Redis 是否存在 used_nonce:abc123，而没同步校验该 nonce 是否真对应这个 timestamp + 当前业务参数，就等于开门揖盗
• Redis 存 nonce 时没设 EX 300，或用了非原子的 SET + EXPIRE，高并发下可能被绕过
• 客户端和服务端对参数排序规则不一致（比如一个按 ASCII、一个按 UTF-8 字节序），导致签名计算结果不同，合法请求被拒

hash_hmac 签名必须覆盖 timestamp、nonce 和全部业务参数

签名不是可选项，是防重放的唯一可信锚点。用 hash_hmac('sha256', $data_string, $secret_key)，且 $data_string 必须严格生成：

• 所有参与签名的参数（包括 timestamp、nonce、order_id、amount 等）先按 key 字典序升序排列
• 每个 value 必须 urlencode()，不能直接拼接（否则空格、中文、+ 号全乱）
• 拼接格式为 k1=v1&k2=v2×tamp=1714465200&nonce=abc123，结尾不加 &，开头不加 ?
• 密钥 $secret_key 绝不能硬编码在前端，也不能写死在 config.php 里被 Git 提交——应从环境变量或 Vault 加载

示例片段（服务端验签逻辑）：

$params = $_POST; // 或 $_GET，视接口约定
unset($params['sign']); // 先剔除 sign 字段
ksort($params); // 强制字典序
$data_string = http_build_query($params, '', '&', PHP_QUERY_RFC3986);
$expected_sign = hash_hmac('sha256', $data_string, $_ENV['API_SECRET']);
if (!hash_equals($expected_sign, $params['sign'] ?? '')) {
    http_response_code(401);
    die('Invalid signature');
}

Redis 存 nonce 的三个硬性要求

用 Redis 做 nonce 去重，不是“存一下就行”，必须满足原子性、时效性、一致性：

• 必须用 SET used_nonce:abc123 1 EX 300 NX（NX 是关键，保证仅当 key 不存在时才设）；禁止拆成 EXISTS + SET + EXPIRE
• EX 300 的值要 ≥ 时间戳允许偏差（如 ±5 分钟 → 至少 600 秒），否则可能因服务器间时间差导致误判
• 如果单个 Redis key 成为热点（比如某用户高频调用），考虑分桶：用 used_nonce_{$nonce[0].$nonce[1]}:abc123 把 nonce 按前两位哈希到 256 个 key 中

调试时最容易忽略的三个细节

上线前不验证这三点，90% 的防重放机制会在真实流量下失效：

• 客户端传的 timestamp 是毫秒级？服务端 time() 是秒级 —— 直接导致 abs($now - $received_ts) > 300 永远为 true。统一强制转为整数秒：(int)round($received_ts / 1000)
• 日志里只记 "nonce abc123 accepted"，但从不记录 SET 命令的返回值（true/false）。调试阶段必须打印 $redis->setex(...) 的返回结果，确认是否真写入成功
• 本地开发用 file-cache，测试环境用 Redis，生产用 Redis 集群 —— 三套配置下 exists 和 setex 行为可能不一致，尤其集群模式下 key slot 分布影响原子性

真正卡住人的从来不是“怎么写签名”，而是参数排序那一行代码在 UTF-8 和 Latin-1 环境下行为不一致，或是 Redis 连接复用导致 pipeline 中的 SETNX 被吞掉返回值。

本篇关于《时间戳加随机数防重放攻击教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！