密码安全与会话安全( 四 ) 对于登录大家并不陌生

会话标识传输安全
XSS攻击叫做跨站脚本攻击，指用户的输入拼接了正常的html+js+css ，变成了带有攻击性的html+js+css 。浏览器可能无法识别具有攻击性的html+js+css ，按照正常的逻辑执行代码，这可能会导致攻击人偷走cookie（XSS还有其他的危害，但这里仅讨论与会话标识相关）。如果黑客在html中插入隐藏的form表单，通过document.cookie()获取到浏览器中cookie ，作为参数并自动发送post请求到攻击人的后端api中，攻击人就可以拿到用户的cookie ，也就可以拿到sessionId了。这种方式可以通过设置cookie的HttpOnly为true来防止js获取cookie值。从而避免通过XSS攻击获取sessionId 。
CSRF攻击叫做跨站请求伪造。 XSS攻击是指本网站的代码执行攻击脚本造成了对本网站的影响。 CSRF攻击则是用户打开了其他网站，浏览器执行了其他网站的攻击脚本，却对本网站造成了伤害。举个例子，当我在浏览器中登录了某银行的网站，进行了转账操作，浏览器调用了https://www.xxx.com/transfertoBankId=123456&money=100 ，我的账户少了100块，收到短信扣了100块。这时来了一封邮件，标题为你想得到力量吗？内容是一个链接，我点击这个链接，看到url是www.yyy.com/index.htm ，立马又收到一个短信，我账号又少了1000块，我刷新下页面，又少1000块。打开页面查看源码，发现有个隐藏的标签，src=https://www.xxx.com/transfertoBankId=123456&money=1000 。也就意味着每次刷新页面，浏览器都会执行一次https://www.xxx.com/transfer?toBankId=123456&money=1000GET请求。
大多数浏览器有同源策略（协议主机端口组成源），其中一个限制是同源的网页才会共享cookie 。但浏览器对html标签有白名单， img就是其中之一，通过img标签的 src就可以发送get请求，因访问的是xxx(银行)的域名，携带了cookie ，银行认为是合法请求，转账成功。因img是get请求，那把转账等高危操作改成post接口不就可以了?也不行，因为form表单的post请求也在白名单中。
CSRF攻击之所以成功，是因为攻击人可以完全伪造用户的请求，那让攻击人无法伪造就可以解决这个问题了。在转账时，要求用户再次输入密码或输入验证码，就可以解决CSRF攻击。转账操作可以这么做，发表评论这类的操作，每次都要求用户输入密码或验证码用户体验就很很差了。
还有Referercheck ，浏览器发送请求时，携带Refererheader ，值为网站url中的域名，异常转账时，虽然调用的www.xxx.com的api ，但referer值为www.yyy.com 。在服务端只要验证Referer值就可以判断这是不是一个CSRF攻击。这种方式也有问题，就是完全相信了第三方（浏览器）。对于低版本的浏览器已经有办法可以篡改Referer值，高版本的浏览器目前无法篡改，如用户使用低版本的浏览器， Referercheck将无法保证安全性。
那还有什么办法可以解决CSRF攻击的问题?我们来看下okta是如何做到解决这个问题的。我们登陆okta成功后，打开网页源代码查看html ，搜索token可以看到

文章图片
在span中保存了一个token值我们再创建一个tab页

文章图片
打开浏览器的f12 ，查看网络请求，可以看到requestheader中有x-okta-xcrftoken这个header 。

文章图片
这就是为了解决CSRF攻击的方式：CSRFToken方式.
csrftoken工作原理就是在用户登录成功后，服务端生成token并保存一段时间，返回给浏览器，浏览器保存在html标签中。当用户操作访问后端api时，将该token放入requestheader中。后端验证该token的合法性即可判断是否是CSRF攻击。这种方式能生效的重点在于攻击人无法拿到目标网站的html 。