学前端网络安全这块还不懂？细说CSRF

本文主要是介绍学前端网络安全这块还不懂？细说CSRF，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

什么是CSRF？

举个栗子，比如我们需要在某个博客上删除一个文章，攻击者首先在自己的域构造一个页面，使用了一个img标签，其地址指向了删除博客的链接。攻击者诱使目标用户，也就是博客主访问这个页面，该用户看到了一张无法显示的一张图片，这时候在回头看看该博客的这篇文章，发现文章已经被删除了，原来刚才的图片链接香博客服务器发送了一个get请求，而这次请求，导致了博客上的一边文章被删除了。在整个攻击过成功，攻击者仅仅诱使用户访问了一个页面，就以该用户身份的第三方站点里执行了一次操作。这个删除博客文章的请求都是攻击者所伪造的，所以这种攻击就叫做“跨站点请求伪造”。

浏览器cookie策略

攻击者伪造的请求之所以能够被服务器验证通过，是因为用户的浏览器发送了cookie的缘故。浏览器所持有的cookie分为两种：一种是‘Session Cookie’,又称“临时Cookie”：另一种是“Third-party Cookie”,也称为“本地Cookie”。两者的区别在于，后者是服务器在Set-Cookie时制定了Expire实践，只有到了Expire时间后Cookie才会失效，所以这种Cookie才会失效，所以这种Cookie会保存在本地：而Session Cookie则没有制定Expire时间，所以浏览器关闭后，Session Cookie就失效了。

在浏览网站过成功如果一个网站设置了Session Cookie,那么在浏览器进程的生命周期内，即使浏览器新打开了Tab页， Session Cookie也都是有效的。Session Cookie保存在浏览器进程的内存空间中；而Third-party Cookie则保存在本地。

在当前的主流浏览器中，默认会拦截Third=party Cookie的有：IE6、IE7、IE8、safari；不会拦截的有火狐2、火狐3、oprea、Google Chrome、Android等。

但若CSRF攻击的目标并不需要使用Cookie，则也不必顾虑浏览器的Cookie策略了。

P3P头的副作用

尽管有些CSRF攻击实施起来不需要验证，不需要发送Cookie，但是不可否认的是，大部分敏感或重要的操作是躲藏认证之后的。因此浏览器第三方Cookie的发送，在某些程度上来说是降低了CSRF攻击的威力。可是这一情况在P3P头介入后变得复杂起来。P3P header是w3c制定的一项关于隐私的标准，如果网站返回浏览器的Http的头中包含有P3P头，则在某种程度上来说，将允许浏览器发送第三方Cookie。

举个栗子，前端通过iframe去加载一段后端代码，后端代码尝试设置set-Cookie，浏览器会受到一个cookie，如果setcookie成功，再次请求该页面时，浏览器会发送刚才收到的Cookie。可是由于跨域显示，set-cookie是不会成功的，所以无法发送刚才收到Cookie。这里无论时临时Cookie还是本地Cookie都一样。第二次发包，只是再次接收到Cookie，上次set-COOKIE的值并不曾发送，说明没有Set-Cookie成功。但是这种情况在加入P3P头后会有所改变，P3P头允许跨域访问隐私数据，从而可以跨域Set-Cookie成功。

P3P头的介入改变了隐私策略，从而使得iframe，script等标签在IE中不在拦截第三方Cookie的发送。P3P头只需要由网站设置一次即可，之后每次请求都会遵循此策略，而不需要再重复设置。

P3P头目前是网站的应用中被广泛应用，因此CSRF的防御中不能依赖于浏览器对第三方Cookie的拦截策略。

请求方式

在CSRF攻击流行之初，曾经认为只能由Get请求发起的，因此很多开发把一些重要操作改成了post请求，但是这种观点是错误的，主要原因是因为大多数的CSRF的攻击发起都是通过标签属性，这类标签只能够发起一次get请求，而不能发起post请求。

可行的CSRF的防御

1. 验证码

验证码是被认为对抗CSRF攻击最简洁有效的防御方法。强制用户必须与应用进行交互，才能完成最终请求。因此，验证码能够很好的遏制CSRF。但是非万能的，不可能在用户的所有操作上加上验证码，只能当做辅助的一种手段，而不能作为最重要的解决方案。

2. Referer Check

这种方法可以被用于检查请求是否来自合法的“源”。常见的互联网应用，页面与页面之间都具有一定的逻辑关系，这就是使得每个正常请求的Referer具有一定的规律。缺陷在于，服务器并非什么时候都能拿到Referer。很多用户处于隐私保护考虑，限制了Referer的发送。在某些情况下，浏览器也不会发送Referer，比如从Https跳转到Http，出于安全考虑，浏览器也不会发送Referer。所以该方法也不能作为主要手段。

Token

CSRF的本质：重要操作的所有参数都可以被攻击者猜测到。攻击者只有预测出URL的所有参数与参数值，才能成功地构造出一个伪造的请求；反之，攻击者无法攻击成功。因此我们需要一个更加通用的解决方案帮助解决这个问题，这个方案就是使用token。

token是随机的，也是不可预测的。token需要足够随机，必须使用足够安全的随机数生成算法，或者采用真随机数生成器。token应该相当于一个‘秘密’，为用户与服务器所共同拥有的，不能被第三者知晓。在实际应用中，token可以放在用户的Session，cookie，localstorage中，由于token存在，攻击者无法在构造出一个完成的url实施CSRF攻击。 token需要同时放在表单和Session中，在提交请求时，服务器只需验证表单中Token与用户Session中的Token是否一致，如果一致，则认为是合法请求；如果不一致，或者有一个为空，则认为请求不合法，可能发生了CSRF。

防御CSRF的token，是根据 “不可预测性原则”的设计方案，所以token生成一定要足够随机，需要使用安全的随机数生成器生成token。token目的不是为了防止重复提交。所以为了使用方便，可以允许在一个用户有效生命周期内，在token消耗掉前都使用同一个token。但是如果用户已经提交表单，则这个token已经消耗掉，应该再次重新生成一个新的token。

使用token时应该注意token的保密性，token如果出现在某个页面的url中，则可能会通过Referer的方式泄露。使用token时，应该尽量吧token放在表单中，把get变为post，避免token泄露。

CSRF的token仅仅用于对抗CSRF攻击，当网站还同时存在XSS漏洞时，这个方案就会变得无效，因为Xss可以模拟客户浏览器执行任意操作。在XSS攻击下，攻击者完全可以请求页面后，读出页面内容的token值，然后在构造出一个合法的请求。这个过程称为XSRF，这里不做详细阐述。

各位大佬，献丑了！！