CSRF

CSRF（Cross Site Request Forgery），中文翻译为跨站请求欺骗攻击，是一种利用了浏览器漏洞的一种攻击手段，常被黑客用作刷接口的手段。

Cookie

Cookie是保存在浏览器本地的一些数据，通常服务器会将和用户有关的数据，如登录token存放在Cookie中。浏览器有一套对Cookie的保护措施，比如Cookie按域（domain）存储，Cookie在别的域下是不可见的。

CSRF 原理

浏览器中的Cookie按照域（Domain）存储，不同域下的Cookie彼此不可见。但是从别的域下发来的请求却能带上这个域的Cookie。带上Cookie是好事，但不可避免的产生一些坏结果，因为Cookie中往往存储了用户的登录token，这使得来自别的域的请求自动处于登录状态，这意味着别的域的请求能模拟用户做出任何事情，比如批量发帖，批量删帖等。

列子

小明是某某社区的用户

他在浏览器上登录了社区，这时社区服务器给小明的Cookie中加上了社区的登录Token
小明登录了另一个奇怪的网站
这个奇怪的网站中隐藏了一串奇怪的js代码，它不停的给社区发送发帖请求
社区服务器接受到请求，由于请求中有小明的Cookie，因此默认小明为登录状态，同意了他的发帖请求
如果很多用户招收攻击，大量的写请求会让社区服务器不堪重负。
黑客在小黑屋里得意的微笑，手里数着刚刚寄来的钞票。

预防

利用浏览器特性

校验请求Header中的refer字段，如果请求不在白名单内，则直接返回405
给Cookie中的重要字段设置上same site属性，这样别的域的请求就无法带上这个Cookie
利用浏览器特性的防御手段都及其简单，但由于浏览器特性并不是所有市面上的浏览器都支持（比如老版本IE则可能不支持），因此有一定的风险

利用Cookie的可见性

虽然跨域请求能带上Cookie，但请求前却无法看到Cookie中的内容，那么我们只要在Cookie中加上一个字段（X-CSRF-TOKEN）并在别的地方如Header中加上一个一模一样的字段，在服务器收到请求时校验这两个字段是否一致，便能防御CSRF攻击。
生成X-CSRF-TOKEN有两种策略：
1.在登录时由服务器下发给Cookie。
2.前端通过随机数生成，当发送请求时，发现Cookie中没有X-CSRF-TOKEN字段，便给Cookie加上该字段。

实践

实践时我采用了前端随机生成Token的方法，实现过程中也遇到了一些问题。
1.如何生产Token
通过随机数生成的Token实际上就是时间戳。这种随机数是可以被碰撞攻击的。比如用户生成了Token就被CSRF，那CSRF中携带的Token完全可能与我们生成的Token一致。解决方法是通过服务器下发的登录Token+时间戳做一个md5作为X-CSRF-TOKEN。
但这由带来了另一个问题，像登录Token这种重要的数据应该设置为http only，即js不可见，这样才能避免另外一些攻击，因此最好的办法实际是采用服务器下发Token的方式。
2.token放在header中还是放在body里
将Token放在Header中当然是最好的，但在实践中，使用自定义的Header会带来一些跨域的问题。浏览器在遇到跨域并且请求中有自定义Header时，首先它会向服务器发送一个Options请求来获取服务器的跨域策略，即response中的那几个header：
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
因此在服务端我们要在Access-Control-Allow-Methods中加上Options，在Access-Control-Allow-Headers中加上X-CSRF-TOKEN。
然而这还不够，发送Options请求很有可能会失败，如果你有nginx的话。nginx可能会直接将Options请求给拦下来，导致之后的请求无法执行。