解决web系统session劫持

我就是我 2022-05-22 13:41 222阅读 0赞

session劫持是一种比较复杂的攻击方法。大部分互联网上的电脑多存在被攻击的危险。这是一种劫持tcp协议的方法，所以几乎所有的局域网，都存在被劫持  
可能。

两台主机要想进行TCP通信，必须经过一个三次握手的过程。三次握手过程中服务端和客户端一般会协商一个序列号。这个序列号一般是一个长整数。用来标记  
每个数据包本来的顺序。服务端或者客户端使用这个序列号来重组在网络传输过程中乱序了的数据包。服务端和客户端在三次握手过程中还会协商其他的内容  
比如window  
size用来通知对方自己可以缓存多少个数据包，以防止某一方过快发送数据包导致丢包。

下面简述一下三次握手的过程：  
假设A想要和B进行通信。  
A会先发给B一个TCP数据包。这个数据包中的SYN标志被置位，因此又将这个数据包叫做SYN数据包。在这个数据包中会包含A的Window  
size信息，并且会包含一个ISN(Initial Sequence  
Number)号，就是初始序列号ISNA。好像最初的ISN号码固定从一个数字开始，这样更容易被人劫持，所以后来这个数字变为了一个伪随机数。这个值的取值范  
是0到2^32-1。这个数据包中不带负载数据。

B在收到SYN数据包后会返回一个SYN+ACK数据包，这个SYN+ACK数据包用来告诉A:  
“我收到了你的SYN数据包”。同时B会将A发过来的ISNA号，原封不动地插入这个ACK数据包。并且将自己的ISNB号码放入这个ACK数据包中返回给A。这个数据包  
同样不会带任何的负载数据。

A收到B的ACK数据包时，同样会返回给B一个ACK数据包表示成功收到对方的数据包。同时A也会将B发送来的ISNA数据+1，放入这个ACK数据包返回给B。这个数据  
包中可以携带负载数据，也可以不携带负载数据。（因为这时连接已经建立了）

通过上面的三次握手之后，一个完整的TCP连接就建立好了。

之后的序列号都是主机收到的数据包中的序列号+收到包中的数据大小。第三次握手中，如果ACK数据包中携带数据，那么ISNA就不再是+1了。而是+数据大小。

Session Hiject

TCP协议在设计之初并没有考虑太多安全的因素。Session都是通过客户端IP，客户端Port，服务端IP，服务端Port来验证的。

session劫持一般发生在A和B建立连接之后的通信过程中。Hacker一般会首先监听网络上的通信数据包。在某次通信过程中，Hacker在B发送信息给A之前，假冒  
B发给A一个数据包。这个数据包中使用B的IP和端口，并且将上次B收到的序列号+此数据包的数据大小作为序列号。在A收到这个数据包时，就会以为这个数据  
是B发给他的。同时A会根据Hacker发给他的数据包修改自己的序列号。如果真正的B尝试发送数据包给A时，A会因为序列号不正确抛弃这个数据包(这时因为B没  
有收到A的响应，所以会重发这个数据包，而这个数据包在发送到A之后又被抛弃)从此Hacker就可以代替B和A通信了。

完成这个过程一般需要一下3个步骤：  
1、监控，跟踪某个Session通信过程。  
2、破坏Session同步通信。  
3、劫持这个Session。

下面简述一下实现以上三个步骤的过程。  
1、通过简单的sniff就可以监听网络上的数据包。  
2、要想破坏Session同步，我们需要预测数据包的序列号。如果我们有权限访问网络，那就可以sniff到网络通信过程，并且从数据包中可以计算出下个序列号  
。这就是本地session劫持。如果我们没有权限，不可以sniff到客户端和服务端的通信过程，那就比较麻烦了。预测序列号是很不可能的，因为可选范围太大  
。(2^32中可能性)  
在如法预测序列号的时候，可以通过ARP欺骗的方法对客户端和服务端来个中间人攻击。这样就可以使两者之间的通信都在Hacker的监控之下。  
3、在上面两个步骤完成之后，就只剩下重组数据包，并且发送给通信的某一端了。重组数据包有很多中方法和现成的工具。这里就不说了。

有很多工具可以用来做Session劫持，有商业的，也有开源的。

这里只提供一些大概的思路：

数据库设计：

logininf表(登录状态表)要有userid, sessionid, workstation(ip), agent(request), hashticket.

1， 在登录成功后，把登录时request的ip, agent，并把sessionid+ip+agent的hash记入logininf表

2，在每次页面访问时，获取request的ip，agent，利用sessionid+ip+agent hash的结果同logininf表里的hashticket比较，如果相同则表明该session是合法的，不同则表示该session和登录时的 session要么不在同一台机器上，要么浏览器等其他因素改变，极有可能是session篡改。