session劫持
黑客可以窃取一个正在进行中的session，被称为session劫持。
session的工作原理
当一个用户身份认证成功后，web服务器会分配一个sessionId，接下来的每个子请求都会携带这个sessionId，服务器会识别每次请求携带的sessionId。除了
sessionId，服务器也会将其他信息和sessionId一起存储。如用户名称，用户最近的活动，或者当前购物车中的项目等。
session有两种普遍的实现：
服务器session
传统模式的session管理，服务器在内存中保存session状态。客户端和服务器互相传递sessionId。常用的方式是将sessionId保存在Header的cookie中。
客户端session
服务器通过将所有的会话状态设置到cookie中，来实现客户端session。而不是只是传递sessionId。服务器通常将session状态编码为JSON。
使用客户端session后，一个网站的多个服务器之间不需要共享状态。每个服务器都可以处理重新连接的请求。便于扩展成千上万的并发用户。
客户端session有一个明显的安全问题，一个恶意用户可以轻松操控session cookie或者整体伪造。一种解决方案是将session cookies加密，然后发给客户端。
客户端返回后，服务器再解密。任何操作或者伪造cookie都会破会加密，并让cookie不可用。另一种是对session进行签名。
session如何被劫持
攻击者通过三种方法劫持session：session窃取，利用SessionId的弱点。
session窃取
攻击者从授权用户盗取cookie header的值来达到目的。主要有三种手段，1：在用户与站点交互时，将恶意代码注入站点。2：嗅探网络流量拦截HTTP头 （中间人攻击）。3：在站点已经通过身份认证时，出发对站点的异常请求（CSRF）。 有幸的是，现代大部分的浏览器都实现了对这三种威胁的安全手段。
- 跨站脚本
为了阻止跨站脚本的攻击，泄露cookie，可以将Set-Cookie设置为只读，这告诉浏览器cookies对js代码不可用。Set-Cookie: session_id=278283910977381992837; HttpOnly - 中间人攻击
为避免中间人攻击，网站应该使用HTTPS，在启用HTTPS后，需要将cookies设置为Secure，这样浏览器就不会通过HTTP发送Cookie了。Set-Cookie: session_id=278283910977381992837; Secure - CSRF
使用CSRF的攻击者不需要访问用户的cookie，只需要诱导用户点击链接，然后执行恶意操作。
利用SessionId的弱点
一个更加直接的方法是猜测sessionId。因为SessionID是随机数字，随机会使用种子，如系统的时钟。如果攻击者可以确定足够的种子值。他们可以枚举出可用的
sessionId来测试你的系统。早期的apache就有这个漏洞，随机sessionID生成使用的算法是系统时钟，这样就可以缩小范围来猜测正确的sessionId。
确保你的站点使用足够大的sessionId不被猜测出来，并使用健壮的随机生成算法。