标题：重放攻击
简介
重放攻击（Replay Attacks）又称重播攻击、回放攻击或新鲜性攻击（Freshness Attacks），是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。
它是一种攻击类型，这种攻击会不断恶意或欺诈性地重复一个有效的数据传输，重放攻击可以由发起者，也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发给认证服务器。从这个解释上理解，加密可以有效防止会话劫持，但是却防止不了重放攻击。重放攻击任何网络通讯过程中都可能发生。重放攻击是计算机世界黑客常用的攻击方式之一，它的书面定义对不了解密码学的人来说比较抽象。重放攻击(5张)
重放攻击的类型
根据消息的来源：1.协议轮内攻击：一个协议轮内消息重放  重放攻击示意图2.协议轮外攻击：一个协议不同轮次消息重放根据消息的去向：1.偏转攻击：改变消息的去向
2.直接攻击：将消息发送给意定接收方其中偏转攻击分为：1.反射攻击：将消息返回给发送者
2.第三方攻击：将消息发给协议合法通信双方之外的任一方
重放攻击详情
详情内容重放攻击是计算机世界黑客常用的攻击方式之一，所谓重放攻击就是攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程。
为了抵御重放攻击，现在的身份认证一般采用“挑战应答”（Challenge/Response）方式。
用户                           系统
-----申请登陆----〉
〈---发送挑战值----
客户端计算相应的应答值
（可以用MD5算法计算应答值）
------发送应答值--〉
系统通过同样的算法
判断应答值是否正确
〈---通过认证（正确）--
不正确则断开连接
这里要注意的是挑战值得熵值必须大（变化量要很大，一般为随机数），若挑战值变化量不大，攻击者只需截获足够的挑战应答关系，就可以进行重放攻击了。（具体“挑战应答”方式流程可见HMAC算法应用）典型例子重放攻击与cookie
我们监听http数据传输的截获的敏感数据大多数就是存放在cookie中的数据。其实在web安全中的通过其他方式（非网络监听）盗取cookie与提交cookie也是一种重放攻击。我们有时候可以轻松的复制别人的cookie直接获得相应的权限。关于cookie，我想应该用单独的一篇文章来说明，在这里就不重复了。
重放攻击的防御方案
时间戳“时戳”──代表当前时刻的数
基本思想──A接收一个消息当且仅当其包含一个对A而言足够接近当前时刻的时戳
原理──重放的时戳将相对远离当前时刻
时钟要求──通信各方的计算机时钟保持同步
处理方式──设置大小适当的时间窗（间隔），越大越能包容网络传输延时，越小越能防重放攻击
适用性──用于非连接性的对话（在连接情形下双方时钟若偶然出现不同步，则正确的信息可能会被误判为重放信息而丢弃，而错误的重放信息可能会当作最新信息而接收）  使用时间戳防御重放攻击序号通信双方通过消息中的序列号来判断消息的新鲜性
要求通信双方必须事先协商一个初始序列号，并协商递增方法提问与应答“现时”──与当前事件有关的一次性随机数N（互不重复即可）
基本做法──期望从B获得消息的A 事先发给B一个现时N，并要求B应答的消息中包含N或f(N)，f是A、B预先约定的简单函数
原理──A通过B回复的N或f(N)与自己发出是否一致来判定本次消息是不是重放的
时钟要求──无
适用性──用于连接性的对话
重放攻击是对协议的攻击中危害最大、最常见的一种攻击形式。
会话劫持
会话劫持原理我们可以把会话劫持攻击分为两种类型：1、中间人攻击(Man In The Middle，简称MITM)；2、注射式攻击（Injection）；
并且还可以把会话劫持攻击分为两种形式：1、被动劫持，2、主动劫持；被动劫持实际上就是在后台监视双方会话的数据流，从中获得敏感数据；而主动劫持则是将会话当中的某一台主机"踢"下线，然后由攻击者取代并接管会话。TCP会话劫持如果劫持一些不可靠的协议，那将轻而易举，因为它们没有提供一些认证措施；而TCP协议被欲为是可靠的传输协议，所以要重点讨论它。
根据TCP/IP中的规定，使用TCP协议进行通讯需要提供两段序列号，TCP协议使用这两段序列号确保连接同步以及安全通讯，系统的TCP/IP协议栈依据时间或线性的产生这些值。在通讯过程中，双方的序列号是相互依赖的，这也就是为什么称TCP协议是可靠的传输协议（具体可参见RFC 793）。如果攻击者在这个时候进行会话劫持，结果肯定是失败，因为会话双方"不认识"攻击者，攻击者不能提供合法的序列号；所以，会话劫持的关键是预测正确的序列号，攻击者可以采取嗅探技术获得这些信息。
TCP协议的序列号
现在来讨论一下有关TCP协议的序列号的相关问题。在每一个数据包中，都有两段序列号，它们分别为：
SEQ：当前数据包中的第一个字节的序号
ACK：期望收到对方数据包中第一个字节的序号
假设双方现在需要进行一次连接：
S_SEQ：将要发送的下一个字节的序号
S_ACK：将要接收的下一个字节的序号
S_WIND：接收窗口
//以上为服务器（Server）
C_SEQ：将要发送的下一个字节的序号
C_ACK：将要接收的下一个字节的序号
C_WIND：接收窗口
//以上为客户端（Client）
它们之间必须符合下面的逻辑关系，否则该数据包会被丢弃，并且返回一个ACK包（包含期望的序列号）。
C_ACK <= C_SEQ <= C_ACK + C_WIND
S_ACK <= S_SEQ <= S_ACK + S_WIND
如果不符合上边的逻辑关系，就会引申出一个"致命弱点"。
这个致命的弱点就是ACK风暴(Storm)。当会话双方接收到一个不期望的数据包后，就会用自己期望的序列号返回ACK包；而在另一端，这个数据包也不是所期望的，就会再次以自己期望的序列号返回ACK包……于是，就这样来回往返，形成了恶性循环，最终导致ACK风暴。比较好的解决办法是先进行ARP欺骗，使双方的数据包"正常"的发送到攻击者这里，然后设置包转发，最后就可以进行会话劫持了，而且不必担心会有ACK风暴出现。当然，并不是所有系统都会出现ACK风暴。比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。注意，ACK风暴仅存在于注射式会话劫持。
TCP会话劫持过程
假设现在主机A和主机B进行一次TCP会话，C为攻击者，劫持过程如下：
A向B发送一个数据包
SEQ (hex): X ACK (hex): Y
FLAGS: -AP--- Window: ZZZZ，包大小为:60
B回应A一个数据包
SEQ (hex): Y ACK (hex): X+60
FLAGS: -AP--- Window: ZZZZ，包大小为:50
A向B回应一个数据包
SEQ (hex): X+60 ACK (hex): Y+50
FLAGS: -AP--- Window: ZZZZ，包大小为:40
B向A回应一个数据包
SEQ (hex): Y+50 ACK (hex): X+100
FLAGS: -AP--- Window: ZZZZ，包大小为:30
攻击者C冒充主机A给主机B发送一个数据包
SEQ (hex): X+100 ACK (hex): Y+80
FLAGS: -AP--- Window: ZZZZ，包大小为:20
B向A回应一个数据包
SEQ (hex): Y+80 ACK (hex): X+120
FLAGS: -AP--- Window: ZZZZ，包大小为:10
现在，主机B执行了攻击者C冒充主机A发送过来的命令，并且返回给主机A一个数据包；但是，主机A并不能识别主机B发送过来的数据包，所以主机A会以期望的序列号返回给主机B一个数据包，随即形成ACK风暴。如果成功的解决了ACK风暴（例如前边提到的ARP欺骗或者其他方式），就可以成功进行会话劫持了。HTTP会话劫持Web应用程序是通过2种方式来判断和跟踪不同用户的：Cookie或者Session（也叫做会话型Cookie）。其中Cookie是存储在本地计算机上的，过期时间很长，所以针对Cookie的攻击手段一般是盗取用户Cookie然后伪造Cookie冒充该用户；而Session由于其存在于服务端，随着会话的注销而失效（很快过期），往往难于利用。所以一般来说Session认证较之Cookie认证安全。
会话型cookie也是可以通过程序获得的，换句话说我们进行TCP会话劫持的时候如果针对http会话劫持的话可以截获所有http内容包括Session信息。