session和token的区别

Veröffentlicht am

dvwa中CSRF的high级别中加入了Anti-CSRF token的机制，所以在这里详细讲解一下token的作用，在csrf的学习过程中，感觉最难的还是理解token的工作机制，以及token和session的区别。

session

session的出现由于本身无状态特性的http协议，用户登录某网站后将在服务器创建一个session，然后服务器将分配一个sessionID给用户，接下来用户的操作都将带上该sessionID,这样，整个的操作都在此session下完成，但是后来就会出现一些问题。

session产生的一些问题

由于需要使用sessionID对用户的身份进行验证，所以服务器需要存下所有的sessionID,一个网站登录的人多了，自然需要更多的服务器用于存储sessionID,于是开销就增大了，并且将sessionID集中保存于某一个服务器的情况下，如果该服务器挂掉了，所有用户的会话管理状态将不被承认，下次又得重新登录，基于这种情况下，考虑是否能够让用户保存sessionID,而我们不用?

token的工作机制

基于上面问题的考虑，所以我们想办法对用户的信息进行验证，所以token出现了，token就是所谓的口令，在拥有该口令的情况下，服务器对用户进行验证。

如果某用户登录某网站后，浏览器第一次访问服务器，根据传过来的唯一标识userId,这时候服务器会将userid+一个密钥(只有服务器知道的)通过某种加密算法A，产生一个口令，返回给用户,在下一次用户向服务器发起请求时,将会带上该token。服务将会使用该用户的userid
与只有自己知道的密钥，再次使用算法A产生一个token.与用户的token进行对比，一致则说明验证通过为该用户的操作，请求得以实现。

dvwa中代码的分析

关键代码：

1
2
3
checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' ); //进行口令验证

generateSessionToken(); //产生token

这段代码中前者为用户请求时带上的token,所以前者可能是一个CSRF攻击，我们在用户于登录网站的情况下去点击该攻击链接,由于攻击者的攻击页面所在的地址和用户登录的地址是不同,比如攻击者的服务器在192.168.43.41上，而用户在192.168.43.41,用户信息不同,y以及一些其他的原因，产生的userid是不同的。后者是用户登录该面后产生的token，与前者不同，所以加了验证token的机制后，我们使用low，还有medium级别的攻击链接就不成立。

session和token的区别

token和session其实都是为了身份验证，session一般翻译为会话，而token更多的时候是翻译为令牌；
session服务器会保存一份，可能保存到缓存，文件，数据库；同样，session和token都是有过期时间一说，都需要去管理过期时间；
其实token与session的问题是一种时间与空间的博弈问题，session是空间换时间，而token是时间换空间。两者的选择要看具体情况而定。

虽然确实都是“客户端记录，每次访问携带”，但 token 很容易设计为自包含的，也就是说，后端不需要记录什么东西，每次一个无状态请求，每次解密验证，每次当场得出合法 /非法的结论。这一切判断依据，除了固化在 CS 两端的一些逻辑之外，整个信息是自包含的。这才是真正的无状态。
而 sessionid ，一般都是一段随机字符串，需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢？万一 redis 服务器挂了呢？

方案 A ：我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。
方案 B ：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人。
就这么个差别。

参考链接：https://www.cnblogs.com/imstudy/p/9197787.html
参考链接：https://www.cnblogs.com/xiaozhang2014/p/7750200.html
参考链接：http://www.cnblogs.com/xiekeli/p/5607107.html
参考链接：https://blog.csdn.net/tenfyguo/article/details/6032126

0%