网站安全之——重放攻击

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/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欺骗或者其他方式），就可以成功进行会话劫持了。

Web应用程序是通过2种方式来判断和跟踪不同用户的：Cookie或者Session（也叫做会话型Cookie）。其中Cookie是存储在本地计算机上的，过期时间很长，所以针对Cookie的攻击手段一般是盗取用户Cookie然后伪造Cookie冒充该用户；而Session由于其存在于服务端，随着会话的注销而失效（很快过期），往往难于利用。所以一般来说Session认证较之Cookie认证安全。

会话型cookie也是可以通过程序获得的，换句话说我们进行TCP会话劫持的时候如果针对http会话劫持的话可以截获所有http内容包括Session信息。

 

http://wenku.baidu.com/link?url=6S-V65noXDJe2r-2yuUtafApJCbQCXNxWB7OPewiV08TTbVb2RS49Lafd60-EwSXH-rYnOm6I9Q1Ns4AEmubiD2gjVkfeHMpJ3ZIP-2YN4e