对301重定向到HTTPS前遭遇中间人攻击的分析

Posted 2022-11-25 皖南笑笑生

由于不能改变用户的输入习惯，很多网站在实现全站HTTPS后，选择通过配置强制301的方式让用户的http请求重定向到https，以保障网站的安全性。然而，在用户发起http请求的时候，仍然存在有中间人攻击的风险，这种方案并非是绝对安全的。下面就结合我们最近亲历的一次中间人攻击，来深入分析下这种劫持行为。
事情的起因，是当我们实现全站HTTPS后，对核心页面都部署了监控任务来分析页面的劫持情况。我们惊讶的发现，虽然劫持率有大幅度的下降，然而仍然存在零星的劫持现象。如下图所示，拨测访问http://www.suning.com/并没有按我们预期的那样301重定向到https://www.suning.com/。而是被302临时重定向到了另一个流量页面。

于是，我们下载了拨测中的抓包文件，进行了分析。如下图所示，是发生劫持的TCP流。


过滤出对应的HTTP流如下所示：

很明显，在客户端和服务端通信的链路上发生了中间人攻击，中间人在服务端响应返回之前迅速返回给客户端一个恶意的报文，报文内容是

http://101.201.79.5:12224/dsgeneral?c=suning1&u=https%3A%2F%2Fsucs.suning.com%2Fvisitor.htm%3FuserId%3D29792464%26webSiteId%3D1800%26adInfoId%3D0%26adBookId%3D104049%26channel%3D14%26vistURL%3Dhttp%3A%2F%2Fwww.suning.com%2F&a=hljheb"

（这个劫持的目的是让用户跳转到https://sucs.suning.com/visitor.htm?userId=29792464&webSiteId=1800&adInfoId=0&adBookId=104049&channel=14&vistURL=http://www.suning.com/，虽然最终也访问回到了网站首页，但是通过推广的链接过来的，后期劫持者可以根据推广号流量来结算获取非法收益）
我们来具体分析下整个劫持过程，首先熟悉下Tcp建立连接三次握手和关闭连接的四次挥手过程：


再来具体分析报文

No  Time    Source  Destination Protocol    Length  Info
# 先开始是TCP三次握手，客户端和服务端正常建连
1002    7.646618    192.168.43.112  221.180.236.216 TCP 66  54955→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1028    7.692035    221.180.236.216 192.168.43.112  TCP 66  80→54955 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=128
1029    7.692128    192.168.43.112  221.180.236.216 TCP 54  54955→80 [ACK] Seq=1 Ack=1 Win=65536 Len=0
# 客户端发起http://www.suning.com/请求 Len=645 Seq=1
1032    7.709001    192.168.43.112  221.180.236.216 HTTP    699 GET / HTTP/1.1 
# 注意！这个200响应是中间人返回的恶意报文！ Ack=646 Len=481（中间人报文大小481） Seq=1
1067    7.737546    221.180.236.216 192.168.43.112  HTTP    535 HTTP/1.1 200 OK  (text/html)
# 客户端接受了恶意响应，发起四次挥手，关闭Tcp连接, 注意[Fin,Ack] Ack=482=481+1，是对恶意报文的Ack，服务端报文大小不是481这个值的
1094    7.748966    192.168.43.112  221.180.236.216 TCP 54  54955→80 [FIN, ACK] Seq=646 Ack=482 Win=65024 Len=0
# 服务端应答[Fin,Ack]，但481长度是中间人的报文大小，服务端一脸莫名其妙，所以他的Seq=1，而不是Seq=482（详见四次握手过程）
1099    7.752925    221.180.236.216 192.168.43.112  TCP 54  80→54955 [ACK] Seq=1 Ack=646 Win=16000 Len=0
# 客户端纠结了，你为什么不给我Seq=482，于是决定不停重发[Fin,Ack]，导致服务端被逼不断强制重新响应请求。整个连接因为完成不了四次挥手一直关闭不了，最终超时后客户端重置
1100    7.752960    192.168.43.112  221.180.236.216 TCP 54  [TCP Dup ACK 1094-1] 54955→80 [ACK] Seq=647 Ack=482 Win=65024 Len=0
1101    7.753056    221.180.236.216 192.168.43.112  TCP 210 [TCP Out-Of-Order] 80→54955 [PSH, ACK] Seq=1 Ack=646 Win=16000 Len=156
1102    7.753085    192.168.43.112  221.180.236.216 TCP 66  [TCP Dup ACK 1094-2] 54955→80 [ACK] Seq=647 Ack=482 Win=65024 Len=0 SLE=1 SRE=157
# 服务端响应的正确报文Ack=646 Len=156（而不是481！） Seq=1
1143    7.817449    221.180.236.216 192.168.43.112  HTTP    210 [TCP Spurious Retransmission] HTTP/1.0 301 Moved Permanently 
1144    7.817487    192.168.43.112  221.180.236.216 TCP 66  [TCP Dup ACK 1094-3] 54955→80 [ACK] Seq=647 Ack=482 Win=65024 Len=0 SLE=1 SRE=157
1178    7.885167    221.180.236.216 192.168.43.112  HTTP    210 [TCP Spurious Retransmission] HTTP/1.0 301 Moved Permanently 
...
4729    26.683012   192.168.43.112  221.180.236.216 TCP 54  54955→80 [RST, ACK] Seq=647 Ack=482 Win=0 Len=0

最后，我们可以通过时序图让整个过程更清晰：

要解决这种中间人攻击的问题，建议采用HSTS策略，通过307 Internal Redirect来代替301 Move Permanently，详见《电商网站HTTPS实践之路（三）——性能优化篇》。
另外，本文中的pcap包我共享在http://download.csdn.net/detail/zhuyiquan/9850246，过滤条件可使用tcp.stream eq 20