cookie机制
cookie实际上是一段文本信息,当web浏览器第一次访问某个服务器时,服务器会给浏览器颁发一个cookie,浏览器将cookie保存,当浏览器再次请求该网站时,浏览器会把请求的网址和cookie一同提交给服务器。服务器检查该cookie,得知该用户状态。服务器还可以根据需要修改cookie内容。
session机制
session是服务器端保存的数据结构,用来跟踪用户的状态,客户端的cookie仅保存session ID,以后每次请求将cookie和网址发送,服务器根据session id,就知道该用户是谁了
session和cookie机制的区别和联系
区别:
- session将用户信息保存在服务器端,前端只有session ID,cookie将用户信息保持在前端浏览器中
- session因为用户接触不到客户信息所以更安全
联系:
- cookie是实现session机制的一种方式,初次之外,还可以直接在网址后面添加sid=xxxxx的方式(在用户浏览器禁用cookie的情况下)
如果用户浏览器禁用了cookie怎么办?
现在的浏览器一般禁用cookie,不是完全禁用,而是失去了“持久化”的作用,关闭窗口清楚cookie,所以依然可以登陆网站
- 使用session机制,首先使用URL重写技术在url后面添加Session id,进行身份认证, 或者还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。 如果不允许添加参数,服务器依然发送Set-Cookie的Header,只是客户端会忽略,则每次访问创建一个新的session,之前状态不会保留,登陆状态无法维持
- 使用cookie机制,禁用cookie,会导致登陆状态无法维持
为什么需要cookie,session?
由于HTTP是无状态的协议,指协议对于事务没有记忆能力,如果后续处理需要知道前面的信息,(例如某宝查询该用户之前的购买记录),则它必须重传,这样导致可能每次连接的数据量增大。但是在数据量小的时候它的应答很快
但是客户端和服务器端进行交互的Web应用程序出现后,应用要求需要知道用户都做了什么,例如登陆状态、购物车买了什么等信息,HTTP的无状态严重阻碍了这些应用功能的实现。
为什么不直接将HTTP改成有状态的协议?
- http在传递数据小的时候应答速度很快
- 软件工程角度讲,http已经是一个较为成熟的协议,后面的修改应该是上层的封装,即
有状态协议 = http + cookie 或 = http + session
盗窃cookie的两个场景
- 场景描述
在公司的一台机器上,职员A登陆了网上银行进行了转账操作,之后他删除了cookie,删除了浏览器自动保存的密码,删除了所有的临时文件,然后退出了机器。几分钟后,职员B来使用这台机器,B检查了浏览历史,发现有人曾经登陆过网上银行并且,url里面含有参数JSESSIONID,B随后使用和A相同的JSESSIONID创建了一个cookie,成功登陆进去了A的银行账户
存在的漏洞
session的ID用来追踪一个会话,暴露在url里面作为请求参数很容易就会被利用
防护措施- 不要将JSESSIONID暴露在url中
- 为每个会话创建一个时间戳,代表会话有效期,超过这个有效期,会话无效。
- 最好的方法是将JSESIONID和时间戳time-stamp保存在一个超级cookie里面,然后对这个cookie进行加密处理,每次请求都需要对cookie解密使用里面的信息。
- 用户方面可以在每次登陆后通过点击退出按钮登陆使得JSESSIONID无效。
- 场景描述
和第一个场景类似,但是这次银行将JSESSIONID和time-stamp封装在了超级cookie中并进行了加密处理,职员A在退出时点击了退出按钮,但是hacker依然窃取了他的账户。 (黑客中途截断了用户的请求进而窃取了cookie)
存在的漏洞
时间戳保留时间为了用户可以完成相应的操作,但是hacker只要窃取了用户的cookie便可以同时登陆其账户。
防护措施
cookie再添加一个值叫做Counter/Nonce,一串随机的二进制数字, 每一次请求后,服务器就会修改Counter/Nonce的值以保证同一个超级cookie不会发起二次请求。