![js中有["1","2","3","4"]这样一个string，怎么把它变成array](/aiimages/js%E4%B8%AD%E6%9C%89%5B%26quot%3B1%26quot%3B%2C%26quot%3B2%26quot%3B%2C%26quot%3B3%26quot%3B%2C%26quot%3B4%26quot%3B%5D%E8%BF%99%E6%A0%B7%E4%B8%80%E4%B8%AAstring%EF%BC%8C%E6%80%8E%E4%B9%88%E6%8A%8A%E5%AE%83%E5%8F%98%E6%88%90array.png)
Cookie是保存在浏览器本地的一些数据，通常服务器会将和用户有关的数据，如登录token存放在Cookie中。浏览器有一套对Cookie的保护措施，比如Cookie按域（domain）存储，Cookie在别的域下是不可见的。
浏览器中的Cookie按照域（Domain）存储，不同域下的Cookie彼此不可见。但是从别的域下发来的请求却能带上这个域的Cookie。带上Cookie是好事，但不可避免的产生一些坏结果，因为Cookie中往往存储了用户的登录token，这使得来自别的域的请求自动处于登录状态，这意味着别的域的请求能模拟用户做出任何事情，比如批量发帖，批量删帖等。
小明是某某社区的用户
虽然跨域请求能带上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请求给拦下来，导致之后的请求无法执行。
网上有很多关于防御CSRF攻击的文章，大都雷同。方法主要有三种：
第二种方法大都是通过在form中填充隐藏的csrf_token。这种方法适用于服务器端渲染的页面，对于前后端分离的情况就不太适用了。
针对前后端分离情况，我有两种方法。
浏览器通过JavaScript读取cookie中的Csrf_token，然后在发送请求时作为自定义HTTP头发送回来。
服务器读取HTTP头中的Csrf_token，与cookie中的Csrf_token比较，一致则放行，否则拒绝。
这种方法为什么能够防御CSRF攻击呢？
关键在于JavaScript读取cookie中的Csrf_token这步。由于浏览器的同源策略，攻击者是无法从被攻击者的cookie中读取任何东西的。所以，攻击者无法成功发起CSRF攻击。
