微信公众号网页授权是很多系统接入微信登录的基础能力，其中state参数本意是用来维持请求状态、防止CSRF。但在实际部署中，如果仅仅生成一个随机字符串作为state，攻击者只要截获用户点击授权后跳转回业务的回调地址，就能拿着同样的state反复向系统发起回调请求。这种重放攻击可能导致用户被重复创建、订单被重复提交，甚至在涉及资金或权限变更的场景下造成越权。要避免这类问题，就不能把state当成一次性随机值那么简单，而需要引入时间维度与不可复用机制。
为什么单纯随机数不足以防重放
很多开发者在接入微信网页授权时，会写一段代码生成一个UUID或者十几位随机字符，放进session并拼到授权链接的state参数里。微信回跳时比对state是否一致，一致就认为请求合法。这种做法能挡住大部分跨站伪造，但挡不住重放。因为随机字符串本身没有时间信息，只要攻击者拿到了那一次合法的回调URL，比如 https://ippipp.com/callback?code=xxx&state=abc123，他就可以在浏览器或脚本里多次访问这个地址。
后端如果只校验state等于session里的值，并且校验完不标记消耗，那么第二次、第三次请求依然会通过。更严重的是，如果session因为某种原因没有及时清除，或者系统采用分布式会话且清理不一致，这个state可能在很长时间内都是有效的。由此可见，防重放必须解决两个问题：一是让state有生命周期，过期作废；二是让state被使用一次后就失效，不能二次使用。
引入时间戳可以直接限定state的有效窗口。比如只允许五分钟内完成的授权回调，超过就拒绝。引入随机数则是为了保证在同一时间窗口内不同用户、不同请求的state不可互相猜测。二者结合，既控制了时间，又控制了空间，比单独使用随机数稳妥得多。
时间戳与随机数结合的state生成方案
具体实现时，可以在用户点击“微信登录”按钮、后端准备重定向到微信授权页之前，生成一个state。这个state建议由两部分组成：当前时间戳（精确到秒或毫秒）和一个密码学安全的随机数。为了避免明文暴露，也可以将二者拼接后做哈希，或者直接用拼接字符串并配合后端存储来做校验。
下面是一段PHP示例，展示如何生成带时间戳和随机数的state，并存入Redis设置过期时间。这里使用随机字节转十六进制，再加上时间前缀，保证唯一与不可预测。
<?php
// 生成防重放state：时间戳 + 安全随机数
$timestamp = time();
$random = bin2hex(random_bytes(16));
$state = $timestamp . '_' . $random;
// 存入Redis，设置180秒过期，值可以简单记为1表示未使用
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->setex('wechat_state_' . $state, 180, 'unused');
// 拼接待跳转的微信授权地址
$redirect = 'https://open.weixin.qq.com/connect/oauth2/authorize?appid=wxappid&redirect_uri=' .
urlencode('https://ipipp.com/callback') .
'&response_type=code&scope=snsapi_userinfo&state=' . $state . '#wechat_redirect';
header('Location: ' . $redirect);
exit;
?>
上面的代码把state本身作为Redis key的一部分，并设置180秒自动过期。这样即便攻击者截获了state，超过三分钟再重放也会被Redis缺失而拒绝。同时随机数部分让不同用户的state完全不一样，无法碰撞。
如果业务不想把时间戳明文放在state里，也可以把时间戳和随机数组装成数组，序列化后加密或哈希，只把哈希值发给微信。后端根据哈希去查之前存的结构化数据。不过对于多数中小型系统，明文时间戳加随机数已经足够，因为真正的安全边界在后端存储与过期策略，而不是state字符串本身是否可读。
回调阶段的校验与一次性消耗逻辑
微信用户授权后跳回业务回调地址，后端拿到code和state。此时必须做三步检查：第一，state是否存在于后端存储中；第二，如果存储中记录了生成时间，要确认当前时间减去生成时间小于允许窗口；第三，该state是否已被标记为已使用。只有三项都通过，才用code去换access_token，并立即把state置为已用或删除。
下面示例展示回调中的校验过程，使用Redis的删除操作保证一次性。若删除返回false说明不存在或已删，直接拒绝。
<?php
$state = $_GET['state'] ?? '';
$code = $_GET['code'] ?? '';
if ($state === '' || $code === '') {
http_response_code(400);
echo 'invalid request';
exit;
}
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$key = 'wechat_state_' . $state;
// 使用事务或lua保证原子性删除与检查
$deleted = $redis->del($key);
if ($deleted <= 0) {
http_response_code(403);
echo 'state invalid or replayed';
exit;
}
// 此处state已消耗，安全使用code换用户信息
// 注意：如果之前state里存了用户会话标识，应在此关联
$appid = 'wxappid';
$secret = 'wxsecret';
$url = "https://api.weixin.qq.com/sns/oauth2/access_token?appid=$appid&secret=$secret&code=$code&grant_type=authorization_code";
$resp = file_get_contents($url);
$result = json_decode($resp, true);
if (isset($result['openid'])) {
echo 'login success for ' . $result['openid'];
} else {
echo 'exchange failed';
}
?>
通过del操作的直接返回值判断，我们实现了一次性消耗。即使攻击者在极短时间内并发重放，Redis的删除命令在单线程模型下也会让其中一个请求成功、其余失败，从而避免竞态导致的重复登录。如果需要更严谨，可以用Lua脚本把检查和删除打包成原子操作，防止高并发下出现边角情况。
另外要注意，微信本身有时会因为网络重试向回调发多次请求，所以拒绝重放不等于拒绝所有重复通知。我们的方案恰好契合这一点：第一次合法回调消耗state，后续微信或攻击者的重复包都会被拒，而这正符合防重放目标。对于确实需要接收微信多次推送的其他业务（如支付通知），应使用不同机制，不要混淆网页授权的state模型。
对比其他方案与常见误区
有的团队尝试用JWT来生成state，把过期时间写在token里，后端不存储。这种做法减少了存储压力，但失去了“一次性消耗”能力，因为JWT无状态，你无法标记某个token已用过，除非额外引入黑名单，那又回到存储思路。所以对于防重放，服务端有状态的短时存储是目前最简单可靠的。
还有人误以为微信的code只能换一次token，所以state重放无所谓。确实，微信的code一般五分钟有效且换一次就失效，但攻击者如果就在用户授权后立刻重放，完全可能抢在用户之前用code换走信息，造成会话错乱。而且某些授权模式或低版本接口对code约束不同，不能依赖第三方行为做自己的安全边界。
最后，时间戳窗口不宜过长，建议控制在120到300秒之间。太长给攻击者留了空隙，太短则正常用户网络慢时容易失败。随机数务必用random_bytes或类似密码学安全源，不要用mt_rand，后者可预测性在高并发下会被缩小空间。把这几件事做对，微信公众号网页授权的state防重放就能真正落地。