知道如何对付session劫持（session hijacking）

服务端和客户端之间是通过session(会话)来连接沟通。当客户端的浏览器连接到服务器后，服务器就会建立一个该用户的session。每个用户的 session都是独立的，并且由服务器来维护。每个用户的session是由一个独特的字符串来识别，成为session id。用户发出请求时，所发送的http表头内包含session id 的值。服务器使用http表头内的session id来识别时哪个用户提交的请求。

session保存的是每个用户的个人数据，一般的web应用程序会使用session来保存通过验证的用户账号和密码。在转换不同的网页时，如果需要验 证用户身份，就是用session内所保存的账号和密码来比较。session的生命周期从用户连上服务器后开始，在用户关掉浏览器或是注销时用户 session_destroy函数删除session数据时结束。如果用户在20分钟内没有使用计算机的动作，session也会自动结束。

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劫持防范

cookieonly和token

通过上面session劫持的简单演示可以了解到session一旦被其他人劫持，就非常危险，劫持者可以假装成被劫持者进行很多非法操作。那么如何有效的防止session劫持呢？

其中一个解决方案就是sessionID的值只允许cookie设置，而不是通过URL重置方式设置，同时设置cookie的httponly为 true,这个属性是设置是否可通过客户端脚本访问这个设置的cookie，第一这个可以防止这个cookie被XSS读取从而引起session劫持， 第二cookie设置不会像URL重置方式那么容易获取sessionID。

第二步就是在每个请求里面加上token，实现类似前面章节里面讲的防止form重复递交类似的功能，我们在每个请求里面加上一个隐藏的token，然后每次验证这个token，从而保证用户的请求都是唯一性。

间隔生成新的SID

还有一个解决方案就是，我们给session额外设置一个创建时间的值，一旦过了一定的时间，我们销毁这个sessionID，重新生成新的session，这样可以一定程度上防止session劫持的问题。

createtime := sess.Get("createtime")
if createtime == nil {
    sess.Set("createtime", time.Now().Unix())
} else if (createtime.(int64) + 60) < (time.Now().Unix()) {
    globalSessions.SessionDestroy(w, r)
    sess = globalSessions.SessionStart(w, r)
}

session启动后，我们设置了一个值，用于记录生成sessionID的时间。通过判断每次请求是否过期(这里设置了60秒)定期生成新的ID，这样使得攻击者获取有效sessionID的机会大大降低。

上面两个手段的组合可以在实践中消除session劫持的风险，一方面， 由于sessionID频繁改变，使攻击者难有机会获取有效的sessionID；另一方面，因为sessionID只能在cookie中传递，然后设置 了httponly，所以基于URL攻击的可能性为零，同时被XSS获取sessionID也不可能。最后，由于我们还设置了MaxAge=0，这样就相 当于session cookie不会留在浏览器的历史记录里面。