安全认证中的CSRF-Toy模板网

这篇具有很好参考价值的文章主要介绍了安全认证中的CSRF。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1、什么叫做CSRF攻击

简单地说，就是说恶意网站，虽然没有盗取你的用户名和密码信息，但是却可以伪装成你，然后登录到银行，或者等危险网站，模拟你进行操作。利用的就是cookies这个特性，即浏览器提供的这种简易的自动身份认证功能。

2、解决的办法

检查Referer字段
HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。

这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。

添加校验token
由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再运行CSRF攻击。这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中，其内容是一个伪随机数。当客户端通过窗体提交请求时，这个伪随机数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪随机数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪随机数的值，服务端就会因为校验token的值为空或者错误，拒绝这个可疑请求。

说明：

CSRF攻击的根源在于浏览器默认的身份验证机制(自动携带当前网站的Cookie信息)，这种机制虽然可以保证请求是来自用户的某个浏览器，但是无法确保这请求是用户授权发送。攻击者和用户发送的请求一模一样，这意味着我们没有办法去直接拒绝这里的某一个请求。如果能在合法请求中额外携带一个攻击者无法获取的参数，就可以成功区分出两种不同的请求，进而直接拒绝掉恶意请求。在SpringSecurity中就提供了这种机制来防御CSRF攻击，这种机制我们称之为令牌同步模式。

客户访问的方式如下：

A 现在登录某银行的网站准备完成一项转账操作，转账的连接如下：

https: //bank .xxx .com/withdraw?account=blr&amount=1000&for=zhangsan

可以看到，这个连接是想从这个账户下转账 1000 元到 zhangsan 账户下，假设 A没有注销登录该银行的网站，就在同一个浏览器新的选项卡中打开一个危险网站，这个危险网站中有一副图片，代码如下：

<img src=“https: //bank .xxx .com/withdraw?account=blr&amount=1000&for=lisi” />

一旦用户打开了这个网站，这个图片链接中的请求就会自动发送出去。由于是同一个浏览器并且用户尚未注销登录，所以该请求会自动携带上对应的有效的 Cookie 信息，进而成功完成一次转账操作。这就是跨站请求伪造。

这也就是所谓的跨站伪造请求。就是说这个请求是其他网站伪造的。那么能够携带的写信也就只有cookies了。

所以，令牌同步模式的解决思路如下：

对于前后端分离的系统而言，客户端输入用户名和密码以后，服务端除了要返回成功以外，还需要返回token，然后这个token会存储在cookie当中，同时，服务端也会保存一份。这样客户端再次发送请求时，需要带着这个token访问，服务端会对比客户端此时传送过来的token是不是我的token。那么这个过程，就是由前端浏览器在没有关闭页面时，前端项目存储的，然后二次请求会自己添加到请求当中。

而对于恶意网站这种跨域转发的请求，通常都是一个post的操作，而这个操作的过程，是没有事前获取post界面时就要的token的，所以直接的post请求在后端就是会被拒绝的。

传统web应用的处理思路如下：

对于传统的web应用，为了防止CSRF，那么首先要去获取这个post的页面，在获取的过程中，服务端会生成token，并通过隐藏字段的方式提供给前端。然后前端再次提交这个真的post请求过去，就自动在页面当中携带了token。而跨域为请求，是直接发送post请求，因此只是带有用户名和密码，是没有token信息的。也就是说，如果是，第三方网站跳转过去，就是直接操作的界面，就算是有了cookie，认证通过了，但是因为没有这个请求字段，所以操作是无法成功的。也就是第三方的跳转，是没有人给他插入这个隐藏字段的。

这个过程，有一个非常好的类比，就是，这个过程，就是验证码的过程。文章来源地址https://www.toymoban.com/news/detail-404583.html