Cookie--防劫持的处理

Cookie与session

HTTP天然是无状态的协议, 为了维持和跟踪用户的状态, 引入了Cookie和Session.

• Cookie包含了浏览器客户端的用户凭证, 相对较小.

• Session则维护在服务器, 用于维护相对较大的用户信息.

用通俗的语言, Cookie是钥匙, Session是锁芯.

Cookie简单理解就是钥匙, 每次去服务端获取资源, 需要带着这把钥匙, 只有自己的锁芯(资源), 才能打开.。但是如果钥匙被别人拿了, 那别人就可以冒充你的身份, 去打开你的锁芯, 从而获取你的信息, 甚至挪用你的资金. 这是非常危险的.

XSS与CSRF

• XSS（Cross SiteScripting，跨站脚本攻击）
  是注入攻击的一种，特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径
• CSRF（Cross-site request forgery，跨站请求伪造），
  是通过伪造请求，冒充用户在站内进行操作

Cookie防劫持预防

基于XSS攻击, 窃取Cookie信息, 并冒充他人身份。

1） 方法一：

给Cookie添加HttpOnly属性, 这种属性设置后, 只能在http请求中传递, 在脚本中, document.cookie无法获取到该Cookie值. 对XSS的攻击, 有一定的防御值. 但是对网络拦截, 还是泄露了.

2）方法二：

在cookie中添加校验信息, 这个校验信息和当前用户外置环境有些关系,比如ip,user agent等有关. 这样当cookie被人劫持了, 并冒用, 但是在服务器端校验的时候, 发现校验值发生了变化, 因此要求重新登录, 这样也是种很好的思路, 去规避cookie劫持.

3）方法三：

cookie中session id的定时更换, 让session id按一定频率变换, 同时对用户而言, 该操作是透明的, 这样保证了服务体验的一致性.

4）方法四：

第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。