Python接口自动化❀详解CookieSession登录验证的工作原理

目前绝大多数的系统都少不了登录验证的功能&＃xff0c;这主要是为了保存用户的状态&＃xff0c;以此来限制用户的各种行为&＃xff0c;从而方便有效的控制用户的权限。比如一个用户登录微博、发布、关注、评论等操作都应是在登录后的用户状态下进行的。

实现验证登录的功能主要有COOKIE&Session、JWT两种方式&＃xff0c;这一节我们将先对COOKIE&Session的工作原理做详细的介绍。

我们知道&＃xff0c;HTTP是无状态的。也就是说&＃xff0c;HTTP请求方和响应方之间无法维持状态&＃xff0c;都是一次性的&＃xff0c;它不知道前后的请求都发生了什么。但有的场景下&＃xff0c;我们需要维护状态。最典型的&＃xff0c;一个用户登录微博&＃xff0c;发布、关注、评论都应该是在登录后的用户状态下才能完成的。

这时候就可以引入COOKIE&Session来保存用户的登录状态。

本篇文章主要介绍使用COOKIE-Session来做登录验证的工作原理。

❀ 为什么不能单独使用COOKIE&＃xff1f;

COOKIE是存放在浏览器中的&＃xff0c;可以在浏览器中打开控制台&＃xff0c;选择应用&＃xff0c;找到存储中的COOKIE进行查看&＃xff1a;

当客户端向服务端发送网络请求时浏览器会自动将COOKIE添加到请求头中&＃xff0c;这样服务端就能获取这个COOKIE&＃xff0c;如下&＃xff1a;

知道了这个原理后&＃xff0c;我们就可以想到&＃xff0c;如果在用户登录系统时&＃xff1a;客户端有用户的部分登录信息&＃xff08;比如username、id等&＃xff09;生成一个COOKIE存放在浏览器中&＃xff0c;那么在这之后的每一次网络请求都会自动携带上该COOKIE。

之后让服务端根据请求中是否携带COOKIE并且携带的COOKIE中是否存在有效的username、id来判断用户是否已经登录过了&＃xff0c;这样一来用户的登录状态不就被保存下来了吗&＃xff1f;

回到上面我们提到的微博的例子&＃xff0c;按照这种过程来说&＃xff0c;当用户登录过后COOKIE已经被保存&＃xff0c;这时当用户进行发布、关注、评论等需要登录才能使用的操作时我们就能提前判断是否存在COOKIE&＃xff0c;如果存在并且COOKIE中含有该用户的id&＃xff0c;那么我们就可以允许该用户的这些操作&＃xff08;这些操作一般都是需要用户的id的&＃xff0c;这时就可以从COOKIE中进行获取&＃xff09;。相反的&＃xff0c;如果COOKIE不存在或者COOKIE无效&＃xff0c;那么就禁止该用户的这些操作。

说到这&＃xff0c;你可能会问&＃xff1a;既然一个COOKIE就能实现我们想要的效果&＃xff0c;那为何还要使用Session呢&＃xff1f;

这是因为COOKIE很容易被伪造&＃xff01; 如果我们知道COOKIE中存放的信息是username和id&＃xff08;就算不知道&＃xff0c;也可以在登录后的网站请求的请求体中找到COOKIE&＃xff09;&＃xff0c;那么我们完全可以在不登录的情况下手动向浏览器存储一个伪造的COOKIE&＃xff1a;

说到这&＃xff0c;你应该就明白为什么不能单独使用COOKIE了吧&＃xff01;

❀ Session是如何与COOKIE结合的&＃xff1f;

Session其实是基于COOKIE实现的&＃xff0c;并且Session存储在服务器的内存或者数据库中。

当用户登录成功时&＃xff0c;使用COOKIE&Session的登录验证会进行以下操作&＃xff1a;

1. 由服务端生成Session与SessionId&＃xff1b;

Session一般是根据用户登录的信息&＃xff0c;如用户名、id等进行生成。
如果把Session比作是一把锁&＃xff0c;那么SessionId就相当于是这把锁的钥匙。

2. 服务端将Session存储到内存或者数据库中&＃xff1b;
3. 服务端将SessionId存放到请求的响应头&＃xff08;respone对象&＃xff09;中的Set-COOKIE字段中发送给客户端&＃xff1b;
4. 客户端收到Set-COOKIE后会自动将Set-COOKIE的值&＃xff08;也就是SessionId&＃xff09;存放到COOKIE中&＃xff1b;
5. 之后的每次网络请求都会自动带上COOKIE&＃xff0c;也就是带上这个SessionId&＃xff1b;
6. 服务端收到后续请求时获取请求上的COOKIE&＃xff0c;也就是获取到的SessionId&＃xff0c;然后通过SessionId查询并校验 服务端存储的Session&＃xff0c;若校验成功说明这个SessionId有效则通过此次请求&＃xff0c;反之则阻止此次请求。

❀ 存储问题

为了保存用户的登录信息&＃xff0c;我们需要为每一个登录的用户生成并存储Session&＃xff0c;这势必就会造成以下问题&＃xff1a;

• 如果Session存放到内存中&＃xff0c;那么当服务端重启时&＃xff0c;这些内存中的session都将被清除&＃xff0c;那么所有用户的登录状态都将会过期&＃xff0c;并且当用户量较大时&＃xff0c;过多的内存占用也势必会影响服务端的性能。
• 如果Session存放到数据库中&＃xff0c;虽然能够解决因服务端重启造成用户登录状态过期的问题&＃xff0c;但当用户量较大时&＃xff0c;对于这个数据库的维护也会变得相对困难。
• 如果前端页面中调用的接口来自两个服务器&＃xff08;也就是两套数据库&＃xff09;&＃xff0c;为了实现Session在两个服务器间共享通常会将 Session存放到一个单独的数据库中&＃xff0c;这样就使得整个项目变得更为复杂也更加难以维护。
  

❀CSRF问题

CSRF全称为Cross-site request forgery即跨站请求伪造&＃xff0c;使用COOKIE进行验证的网站都会面临或大或小的CSRF威胁&＃xff0c;我们以一个银行网站的例子来介绍CSRF的攻击原理&＃xff1a;

假如一家银行网站A的登录验证采用的是COOKIEssession&＃xff0c;并且该网站上用以运行转账操作的Api地址为&＃xff1a;http://vwww.grillbankapi.com/&＃xff1f;account&＃61;AccoutName&amount&＃61;1000

api参数&＃xff1a;account代表账户名&＃xff0c;amount代表转账金额。

那么&＃xff0c;一个恶意攻击者可以在另一个网站B上反之如下代码&＃xff1a;

<img src&＃61;"http://www.grillbankapi.com/?account&＃61;Ailjx&amount&＃61;1000">


注意&＃xff1a;img 标签的src是网站A转账操作的api地址&＃xff0c;并且参数account为Ailjx&＃xff0c;amount为1000&＃xff0c;也就是说这个api地址相当于是账户名为Ailjx转账1000时调用的api。

如果有账户名为Aijx的用户刚访问过网站A不久&＃xff0c;登录信息尚未过期&＃xff08;网站A的COOKIE存在且有效&＃xff09;。
那么当Ailjx访问了这个恶意网站B时&＃xff0c;上面的img 标签将被加载&＃xff0c;浏览器就会自动请求img 标签的src路由&＃xff0c;也就是请求http://ww.grillbankapi.com/&＃xff1f;account&＃61;Ailjx&amount&＃61;1000&＃xff08;我们将这个请求记为请求Q&＃xff09;&＃xff0c;并且因为COOKIE存放在浏览器中且浏览器发送请求时会自动带上COOKIE&＃xff0c;所以请求Q上就会自动携带Ailjx在网站A上的COOKIE 凭证&＃xff0c;结果就是这个请求0将会被通过&＃xff0c;那么Aijx就会损失1000资金。

这种恶意的网址可以有很多种形式&＃xff0c;藏身于网页中的许多地方。此外&＃xff0c;攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛&＃xff0c;博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话&＃xff0c;用户即使访问熟悉的可信网站也有受攻击的危险。

透过例子能够看出&＃xff0c;攻击者并不能通过CSRF攻击来直接获取用户的账户控制权&＃xff0c;也不能直接窃取用户的任何信息。他们能做到的&＃xff0c;是欺骗用户浏览器&＃xff0c;让其以用户的名义运行操作。

这些就是使用COOKIE&session来做登录验证的问题所在&＃xff0c;那么我们如何解决这些问题呢&＃xff1f;这就需要引入JWT的概念&＃xff0c;使用token来做登录验证&＃xff0c;这些我们将在之后的文章中进行讲解。

两者的区别&＃xff1a;在安全和性能方面考虑

1、COOKIE数据存放在客户端&＃xff0c;session数据放在服务器上。
2、COOKIE不是很安全&＃xff0c;别人可以分析存放在本地的COOKIE并进行COOKIE欺骗&＃xff0c;考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上&＃xff0c;当访问增多&＃xff0c;会比较占用你服务器的性能&＃xff0c;考虑性能应当使用COOKIE。
4、不同浏览器对COOKIE的数据大小限制不同&＃xff0c;个数限制也不相同。单个COOKIE保存的数据不能超过4K&＃xff0c;很多浏览器都限制一个站点最多保存20个COOKIE。
5、可以考虑将登陆信息等重要信息存放为session&＃xff0c;不重要的信息可以放在COOKIE中。

两者的联系&＃xff1a;
1、都是用来记录用户的信息&＃xff0c;以便让服务器分辨不同的用户。
2、可以搭配使用&＃xff0c;但都有自己的使用局限&＃xff0c;要考虑到安全和性能的问题。