前言
最近在写一个Uniapp项目。涉及到了前后端鉴权的问题。小程序和Uniapp不支持cookies，只能使用localStorage，所以只能采用token鉴权。考虑到js能够直接存取localStorage这个安全问题，所以特意查了一下Storage在浏览器上的安全策略。
Cookies
Cookies是浏览器提供的功能。Cookies是很古老很成熟的HTTP状态保持办法。Cookies可以设置HTTPONLY来阻止恶意js获取SessionID。
Cookies还有同源策略，使用协议+域名/IP+端口号来确定是否是同源，非同源不能读取Cookies。
Cookies一般只能存储4KB字符串内容，Cookies可以设置过期日期。
Storage
Storage是HTML5的存储技术。Storage也是由浏览器提供的功能。Storage在PC端浏览器上能够提供5M左右的存储空间，在移动端浏览器上一般提供2.5M左右的存储空间。Storage也只能存储字符串数据。
Storage分为sessionStorage和localStorage，这两者的不同仅在于sessionStorage存储的数据的在页面关闭也就是session结束的时候就会被销毁，而localStorage数据长期有效除非用户手动清空浏览器数据。
Storage也支持协议+域名/IP+端口号的同源策略，非同源不能读取Storage里的内容。
Storage面临的安全问题
存储型XSS
假设一个没有安全防护的个人空间使用localStorage存储sessionID信息。
同一个网站下的不同URL是符合协议+域名/IP+端口号的同源策略的。假设一个个人空间的URL符合以下逻辑http://a.com/username，那么a用户的个人空间地址为http://a.com/a，b用户的个人空间地址为http://a.com/b。
b登陆之后在首页发表了一篇文章，添加了以下js代码
let sessionID = localStorage.getItem('sessionID');那么在a登陆之后访问b的空间，b就能拿到a的sessionID，从而可以代表a更改各种信息。
如何防止存储型XSS？
- 禁止普通用户编辑、发布带有任何js内容。
- 前端显示之前在字符串前后加
"或者<code>，</code>将用户输入变为字符串输出。
Storage中的数据被偷
隐患来源：
- 大部分浏览器明文存储Storage中的信息。
- DNS劫持
- 中间人攻击
如何防止Storage中的数据被偷？
- 使用DNSSEC
- 只使用https协议。http请求全部重定向到https请求。
- 不支持低级HTTPS秘钥协商协议或算法
Comments | NOTHING