Token 放在 cookie ,localStorage、sessionStorage 中有什么不同

614 阅读3分钟

将 Token 存储于 WEB 存储(localStorage 或者 sessionStorage)

WEB 存储可以通过同一域上 Javascript 访问。这意味着任何在你的网站上运行 JS 都可以访问 WEB 存储,所以容易受到 XSS 攻击,尤其是项目中用到很多第三方的 JS 类库。 为了防止 XSS,一般的处理是避开和编码所有不可信的数据。但是并不能百分之百防止 XSS 的攻击。比如我们使用托管在 CDN 或其它一些公共的 js 库,还有像 npm 这样的包管理器导入别人的代码到我们的应用程序中。 如果你使用的脚本中有一个被盗用了怎么办?恶意的js可以嵌入到页面上,并且web存储被盗用。这些类型的XSS攻击可以得到每个人的web存储来访问你的网站。这也是为什么许多组织建议不要在WEB中存储任何有价值或者新人任何WEB存储中的信息。这包括会话标识符和令牌。作为一种存储机制,WEB存储在传输过程中不强制执行任何安全标准 XSS攻击:Cross-Site Scripting(跨站脚本攻击) 简称XSS,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使之在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如Cookie、sessionID等,进而危害数据安全。

将Token 存储于Cookie

优点:可以指定httponly来防止被JS读取,也可以置顶secure来保证token旨在HTTPS下传输 缺点:不符合Restful最佳实践 容易受到CSRF攻击(可以在服务器端检查Refer和Origin) CSRF:跨站请求伪造,简单来说:是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(比如发邮件,发送消息甚至操作财产)。由于浏览器曾经认证过,所以被访问的网站会以为是真正的用户操作而去运行。这利用了web中用户身份验证的一个bug:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户资源发出的。CSRF并不能够拿到用户的任何信息,它只是欺骗用户浏览器,让其以用户的名义进行操作。

总结

关于token存在cookie还是localstorage有两种观点:

  • 支持Cookie的开发人员会强烈建议不要将敏感信息(例如JWT)储存在LocalStorage中,因为它对于XSS毫无抵抗力
  • 支持LocalStorage的一派认为,撇开LocalStorage的各种优点不谈,如果做好适当的XSS防护,收益是远大于风险的

放在cookie 中看似安全,看似“解决”(因为仍然存在xSS的问题)一个问题,却引入了另一个问题(CSRF) localStorage具有更加灵活,更大空间,天然免疫CRSF的特征。Cookie空间有限,而jwt一般都占用较多字节,而且有时你不止需要存储一个JWT。 确保你的代码以及第三方库的代码有足够的XSS检查,在此之上将token存放在localStorage 中。

在XSS面前,即便你的httpOnly cookie无法被获取,黑客仍然可以诱导或者在用户毫不知情的情况下做任何事情。记住!黑客的代码和你的代码一样被用户信任!XSS只要存在,那么无论将信息存储在LocalStorage还是SessionStorage,都是—样脆弱不堪,唯—的区别只是获取难度。XSS漏洞很难被发现.因为—个网站的构建不仅仅是基于自己的代码,第三方的代码同样以可能存在XSS漏洞。