能否利用客户端SOURCE_PORT伪造TCP报文替换服务器响应？

客户端向服务器发起TCP请求时，操作系统会自动为通信分配源端口（SOURCE port）。典型请求的端口参数为：目的端口（DESTINATION_PORT）80，源端口（SOURCE_PORT）65123。服务器向客户端返回响应时，会将请求携带的源端口作为响应报文的目的端口，自身使用服务监听的80端口作为响应的源端口。

实验场景 #

同一广播域局域网内共3台设备：

• SERVER：响应时延极高的慢速HTTP服务器
• PC1：受害客户端，正常向SERVER发起HTTP请求
• PC2：攻击者控制的设备

正常TCP交互的端口对应规则如下：

PC1 -> SERVER: SOURCE_PORT: 65123, DESTINATION_PORT: 80
SERVER -> PC1: SOURCE_PORT: 80, DESTINATION_PORT: 65123

待验证的攻击流程为：PC2构造特定报文发往PC1，抢在SERVER真实响应前到达，替换PC1收到的服务端响应，构造的伪造报文交互逻辑为：

PC1 -> SERVER: SOURCE_PORT: 65123, DESTINATION_PORT: 80
PC2 -> PC1: SOURCE_PORT: 80, DESTINATION_PORT: 65123

结论 #

该攻击完全可以实现，属于局域网TCP会话劫持的经典手法，只需要满足3个必要条件：

1. 构造报文时必须将IP层的源IP伪造为SERVER的IP。TCP连接通过四元组（源IP、源端口、目的IP、目的端口）唯一标识，仅匹配端口信息的话，PC1的操作系统无法将PC2发来的报文对应到自身与SERVER的现有连接上，会直接丢弃报文。
2. 构造报文的TCP序列号、确认号必须落在PC1当前连接的接收窗口范围内。TCP协议栈会对所有入站报文做序列号校验，不满足窗口要求的报文会被直接丢弃。由于PC2和PC1、SERVER在同一广播域，只需要开启网卡混杂模式嗅探链路流量，就能直接抓取到双方交互的报文，拿到准确的序列号、确认号参数，不需要暴力猜解，实现门槛极低。
3. 伪造的响应报文必须抢在SERVER的真实响应之前到达PC1。题设中已经明确SERVER响应时延极高，这个时间差条件很容易满足。如果要进一步提升攻击稳定性，还可以在伪造响应发送完成后，构造RST报文主动断开PC1与SERVER的TCP连接，避免延迟到达的真实响应触发连接异常。

这类攻击在未做端口安全、ARP防护的局域网环境下成功率极高，早期很多HTTP会话劫持、插入恶意内容的攻击就是基于这个原理实现的。

内容的提问来源于stack exchange，提问作者Rostyslav Bornitskyi