成功劫持了session，遵循gjb 5880-2006标准的软件配置管理

图6.6 模拟cookie 回车后，你将看到如下内容： 图6.7 劫持session成功 可以看到虽然换了浏览器，但是我们却获得了sessionID，然后模拟了cookie存储的过程。这个例子是在同一台计算 机上做的，不过即使换用两台来做，其结果仍然一样。此时如果交替点击两个浏览器里的链接你会发现它们其实操纵 的是同一个计数器。不必惊讶，此处firefox盗用了chrome和goserver之间的维持会话的钥匙，即gosessionid，这是 一种类型的“会话劫持”。在goserver看来，它从http请求中得到了一个gosessionid，由于HTTP协议的无状态性， 它无法得知这个gosessionid是从chrome那里“劫持”来的，它依然会去查找对应的session，并执行相关计算。与此 同时 chrome也无法得知自己保持的会话已经被“劫持”。 session劫持防范session劫持防范 cookieonly和tokencookieonly和token 通过上面session劫持的简单演示可以了解到session一旦被其他人劫持，就非常危险，劫持者可以假装成被劫持者进 行很多非法操作。那么如何有效的防止session劫持呢？ 其中一个解决方案就是sessionID的值只允许cookie设置，而不是通过URL重置方式设置，同时设置cookie的httponly 为true,这个属性是设置是否可通过客户端脚本访问这个设置的cookie，第一这个可以防止这个cookie被XSS读取从而 引起session劫持，第二cookie设置不会像URL重置方式那么容易获取sessionID。 第二步就是在每个请求里面加上token，实现类似前面章节里面讲的防止form重复递交类似的功能，我们在每个请求 里面加上一个隐藏的token，然后每次验证这个token，从而保证用户的请求都是唯一性。 h := md5.New() salt:="astaxie%^7&8888" io.WriteString(h,salt+time.Now().String()) token:=fmt.Sprintf("%x",h.Sum(nil)) if r.Form["token"]!=token{ //提示登录 } sess.Set("token",token) 间隔生成新的SID间隔生成新的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 不会留在浏览器的历史记录里面。 149