小迪Web自用笔记23

身份验证：

Cookie（用户）：用户身份的凭据（这逼玩意儿好像存储在浏览器本地，就比如说记住密码，只要你登录过一次，并且把这些信息存储在浏览器本地之后，下一次浏览器就会自动把这些信息给添加到头部信息。）

cookie的加密全看

讲了cookie的开发逻辑，你只要知道了cookie在它的有效期间就可以登录，不需要做任何操作，得到你浏览器的cookie，就可以浏览你浏览器登录的网站。

我如果我在一个浏览器中获取了用户的一个域名的cookie我可不可以在另一个浏览器中用这个cookie登录？

改包的话可以

 在这段代码的失效本质只是让浏览器中的cookie失效，（也没个凭证）服务器半点校验都没有，所以旧cookie也可以登。

因为代码逻辑非常简单，验证据库中的用户名与密码是否正确，如果正确就把用户名和密码都放在客户端。

>0，是为了验证登录是否正确，如果错误。返回值是零，如果正确返回值是1。

 

核心逻辑错误的直接体现确实在“退出登录”这个操作上——只做了“让浏览器Cookie失效”这一步，没同步处理服务器端的身份校验；但往根儿说，这个错误是由整个认证体系的根基缺陷导致的：

 

1. 直接错误：退出登录的“操作不完整”

 

正常的退出登录，必须是“客户端清Cookie + 服务器端毁凭证”的组合拳，但原代码只打了第一拳：

 

- 客户端：用  setcookie(..., time()-3600)  让浏览器删Cookie，这步没问题；

- 服务器端：啥也没做——既没有“注销”的会话记录（因为本来就没建），也没有“标记旧Cookie失效”的逻辑，相当于“只把自己家门钥匙扔了，却没告诉物业‘这把钥匙作废了’”。

 

所以别人捡了你的旧钥匙（旧Cookie值），物业（服务器）还是会认，照样能开门。

 

2. 根本原因：认证体系“没给服务器留管控权”

 

为什么退出登录只能清客户端Cookie？因为原代码的认证逻辑，从一开始就没给服务器“管控身份”的机会：

 

- 登录时，直接把“用户名+密码”塞给客户端当Cookie，相当于“把身份凭证的生成、存储、校验全交给了客户端”；

- 后续访问，服务器只看“客户端传的凭证对不对”，不看“这个凭证是不是该失效了”“是谁在使用”——服务器根本没有一个“身份凭证管理表”（比如Session表），自然没法在退出时“远程作废”某个凭证。

 

简单说：服务器手里没“账本”，记不住谁的凭证该失效，只能被动接收客户端传来的Cookie值，退出登录时自然只能让客户端自己删Cookie。

 

总结

 

- 表面看：错误是“退出登录只清了浏览器Cookie”；

- 本质看：错误是“整个认证体系没建立服务器端的凭证管控机制”——退出登录的操作不完整，只是这个根基缺陷的“最终暴露”。

 

就像盖房子没打地基，最后墙倒了，表面是墙的问题，实际是地基没做。要解决，不能只补墙（改退出登录），必须先打地基（加Session服务器端管控）。

所以说到底就是这个cookie太简单了用户名和密码都写上面了。而这个方案是，让这个cookie变成另一个唯一的值，然后让服务器校验这个唯一的值是否失效。

 

 

 

Session（服务器）（会话）（如果是PHP中。一般都是session save path中。

存储在服务器上，攻击服务器拿session没必要，你都有服务器权限了，你要这个还有啥用呢？

这玩意就和打电话一样，关闭浏览器就会失效，字如其名，如果你一直没有在浏览器上操作（软件什么的），它就会让你重新登录。

你必须在会开启的时候拿到ID才能登录成功。

这玩意儿会隔段时间在服务器删除（文件）。

 

 

如何判断用的是cookie还是session

*规模：规模大用session规模小用cookie

*时间：你等半个小时再刷新看他退不退出登录。

*直接抓包看有没有跟session相关的。

 

 

token：

提交请求的时候，每一次登录都要生成一个唯一的编号（防爆破）

一般来说就是包里的Token值要跟服务器的token值做对比。