CSRF攻击之所以成功，是因为攻击人可以完全伪造用户的请求，那让攻击人无法伪造就可以解决这个问题了。在转账时，要求用户再次输入密码或输入验证码，就可以解决CSRF攻击。转账操作可以这么做，发表评论这类的操作，每次都要求用户输入密码或验证码用户体验就很很差了。
还有Referer check，浏览器发送请求时，携带Referer header，值为网站url中的域名，异常转账时，虽然调用的 的api，但referer 值为。在服务端只要验证Referer值就可以判断这是不是一个CSRF攻击。这种方式也有问题，就是完全相信了第三方（浏览器）。对于低版本的浏览器已经有办法可以篡改Referer值，高版本的浏览器目前无法篡改，如用户使用低版本的浏览器，Referer check将无法保证安全性。
那还有什么办法可以解决CSRF攻击的问题? 我们来看下okta是如何做到解决这个问题的。我们登陆okta成功后，打开网页源代码查看html，搜索token可以看到
在span中保存了一个token值 我们再创建一个tab页
打开浏览器的f12，查看网络请求，可以看到request header中有x-okta-xcrftoken这个header。
这就是为了解决CSRF攻击的方式：CSRF Token方式.
csrf token工作原理就是在用户登录成功后，服务端生成token并保存一段时间，返回给浏览器，浏览器保存在html标签中。当用户操作访问后端api时非安全黑客脚本全本，将该token放入request header中。后端验证该token 的合法性即可判断是否是CSRF攻击。这种方式能生效的重点在于攻击人无法拿到目标网站的html。
最近在思考一个问题，就是如果黑客同时发起XSS攻击和CSRF攻击卡盟，这种方式是不是也失效了？黑客通过XSS攻击，获取到了CSRF token，攻击人立马发送钓鱼邮件给目标用户，目标用户点击了链接，网站打开时，先从黑客处获取CSRF Token，并携带CSRF Token发起了CSRF攻击，还有个前提是浏览器版本太低没有Referer，那不就可以攻击成功了？（我杞人忧天了吗？） cookie+session有这么多安全需要考虑，那不要cookie+session不就没这么多问题吗?现在流行的jwt就可以做到无session的登录认证，但jwt也有各种各样的安全问题。
下回再聊jwt与单点登录中的安全。
文/Thoughtworks章宾
原文链接：
来源：【九爱网址导航www.fuzhukm.com】 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
