Session本质

提到Session我们能联想到的就是用户登录功能，而本身我们使用Session的基础是通过url进行访问的，也就是使用http协议进行访问的，而http协议本身是无状态的，那么问题来了服务器端是怎么验证客户端身份的？

答：服务器端和客户端验证的联系就是sessionid，登录成功之后服务器会自动给客户端一个session标识也就是sessionid，而sessionid会存储到客户端的cookie里面，每次请求的时候都会带上这个标识，用来让服务器端验证身份的。服务器端的sessionid一般是存储在内存中的，通过某种算法加密存储到服务器上，客户端就存储到cookie里面，当页面关闭的时候客户端的sessionid就会消失，而服务器端的session不会因为客户端的消失而关闭，而是通过他本身设置过期时间之后，才会失效。

总结来说，session本身就是通过存储在客户端的sessionid进行身份验证。

那么问题来了，如果客户端的sessionid被读取到，就可以伪装身份，对系统进行破坏了，这就是存储型XSS了，那怎么来处理怎么问题呢？这就是接下来要说的Cookie了。

Cookie属性HttpOnly

定义：如果cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击，窃取cookie内容，这样就增加了cookie的安全性。

解释：也就是说服务器端设置了HttpOnly之后，客户端是无法通过document.cookie获取到cookie值了，这样就有效的缓解了XSS攻击。

服务器设置HttpOnly方法：

asp.net：

HttpCookie myCookie = new HttpCookie("myCookie");  
myCookie.HttpOnly = true;  
Response.AppendCookie(myCookie);

express(nodejs)：

res.cookie('rememberme','1',{httpOnly: true });  

然而，设置HttpOnly只能一定程度的阻止XSS，如果http在传输过程中被劫持了，该怎样处理这个问题呢？那就是接下来要说的Cookie的另一个属性Secure了。

Cookie属性Secure

定义：当Secure属性设置为true时，cookie只有在https协议下才能上传到服务器，而在http协议下是没法上传的，所以也不会被窃听。

解释：当Secure=true时，客户端的Cookie是不会上传到服务器端的（http协议）。

asp.net

HttpCookie myCookie = );  
@H_502_116@//...
myCookie.SecurePolicy = CookieSecurePolicy.Always;
Response.AppendCookie(myCookie);

express(nodejs)

var app = express()
var sess = {
  secret: 'keyboard cat',cookie: {}
}

if (app.get('env') === 'production') {
  app.set('trust proxy',1)  trust first proxy
  sess.cookie.secure = true  serve secure cookies
}

app.use(session(sess))

参考资料：https://github.com/expressjs/session

末尾

到此，本文已到尾声，主要介绍了Session的原理，以及Cookie两个非常重要的安全属性的设置（HttpOnly/Secure），能力有限，不足之处，欢迎各位斧正~