Web安全实践（13）嗅探，arp欺骗，会话劫持与重放攻击（上）

核心提示： TCP协议的序列号现在来讨论一下有关TCP协议的序列号的相关问题，在每一个数据包中，Web安全实践（13）嗅探，arp欺骗，会话劫持与重放攻击（上）(3)，都有两段序列号，它们分别为：SEQ：当前数据包中的第一个字节的序号ACK：期望收到对方数据包中第一个字节的序号假设双方现在需要进行一次

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为攻击者，劫持过程如下：