重放攻击基础
说起重放攻击，不知道你第一次听到这个词是什么感觉。我刚入行那会儿，觉得这东西挺简单的——不就是把抓到的包再发一遍嘛。后来真正做安全评估才发现，这里面的门道比想象中深得多。
重放攻击（Replay Attack），你想想看，它本质上就是一种欺骗手段。攻击者不需要破解你的密码，也不需要知道你的私钥。他只需要把一个合法的数据流原封不动地再发一次。就这么简单，但后果可能非常严重。
什么是重放攻击
我们先说定义。重放攻击，是指攻击者截获通信双方之间的有效数据包，然后在后续某个时间点重新发送这些数据包，以欺骗接收方。
关键点有三个：
- 截获：攻击者能拿到正常通信的数据
- 存储：攻击者保存了这份数据
- 重放：攻击者在新的会话中重新发送这份数据
核心区别：重放攻击不等于中间人攻击。中间人攻击是实时篡改，重放攻击是拿着历史数据重复使用。我见过不少新人把这两个搞混，其实它们是完全不同的攻击手法。
我在一次安全审计中就遇到过类似案例。某银行的内部系统用的是简单的用户名密码认证，但没有做任何防重放处理。攻击者只要捕获一次登录请求的报文，之后就可以反复使用这个报文登录系统。你想想看，这等于攻击者拿到了一个永不过期的通行证。
常见场景
重放攻击能发生在任何网络通信场景中。我总结了一下，最典型的有这几种：
| 场景 | 攻击方式 | 真实案例（我遇到的） |
|---|---|---|
| 身份认证 | 重放登录请求 | 某OA系统，抓包后直接重放POST请求，成功登录他人账号 |
| 金融交易 | 重放转账指令 | 客户反馈账户被重复扣款，查日志发现是同一笔交易报文发了多次 |
| API调用 | 重放接口请求 | 某开放平台的重置密码接口，重放后反复收到重置邮件 |
| 物联网设备 | 重放控制指令 | 智能门锁的开锁指令被截获后，攻击者可以随时开门 |
| OCSP/证书 | 重放撤销状态响应 | 这是我本章重点要讲的内容，后面会展开 |
我个人习惯把场景分成两大类：
- 主动式重放：攻击者截获数据后，立即在当前会话中重放。比如你用同一个令牌连续发多次请求。
- 延迟式重放：攻击者截获数据后，等一段时间再重放。比如今天的天气预报请求，明天再发一遍，服务器如果没校验时间戳，就会返回昨天的结果。
注意：延迟式重放往往更容易被忽视。因为日志里看，所有请求都是合法的，只是不在正确的时间点。我曾经帮一个客户排查问题，发现他们的API在凌晨3点突然收到大量白天的请求，就是典型的延迟重放攻击。
危害归纳总结
重放攻击的危害，说白了就是打破了你对通信安全的所有预期。你以为加密了，安全了，其实攻击者根本不需要解密。只要你没做防重放保护，加密也是白加密。
我归纳了以下几个层面的危害：
- 身份冒充：攻击者重放认证报文，以合法用户身份执行操作。这是最常见的危害。
- 状态欺骗：比如OCSP场景中，攻击者重放一个旧的"证书有效"响应，让系统误以为已撤销的证书仍然有效。
- 交易重复：金融系统中，同一笔转账请求被重放多次，导致资金被多次划走。
- 资源浪费：攻击者重放大量合法请求，占用服务器资源，造成服务降级甚至拒绝服务。
- 信息泄露：通过重放某些特定请求，攻击者可以获取历史数据，推测出系统的状态变化。
我的建议：在做安全设计时，不要把精力全放在加密上。加密防的是数据泄露，但防重放需要的是唯一性校验和时效性校验。这两者缺一不可。
举个更具体的例子。我之前参与过一个政务系统的安全评估，他们的接口全用了HTTPS。项目组觉得这样就很安全了。结果我拿了个代理工具抓了下包，发现某个状态查询接口的请求没有任何防重放机制。我当天截获了一个"查询通过"的响应包，第二天重放了一遍，系统照单全收。你想想看，如果这个接口是审批类的，那后果就不堪设想了。
避坑指南：我曾经遇到过一种情况，客户说他们的系统用了TLS，所以重放攻击不可能。但实际呢？TLS保护的是传输层，而重放攻击利用的是应用层的漏洞。TLS只能保证数据在传输过程中不被篡改，但无法阻止一个合法的历史请求被重新发送。嗯，这里面有根本性的区别。
最后，我想强调一点：在OCSP场景下，重放攻击的危害格外隐蔽。因为OCSP响应本身是有签名的，攻击者不能篡改内容，但他可以重放一个旧的响应包。比如说，一张证书在2024年1月1日被撤销了，但你手头还有一个2023年12月31日签发的"证书有效"的OCSP响应。攻击者把这个响应重放给你，你就会认为证书依然是有效的。这就是我接下来几章要重点讲的内容——如何检测并防御这种OCSP响应重放。