anti-CSRF Token布署时需要注意的一点问题

防范CSRF攻击的方案有许多种，有用验证码来防的(tenfy:方案比较重，适合于敏感数据的变更类操作，对一般查询信息类不是很合适)，更多的是生成一个随机的token，当用户提交的时候，在服务器端比对一下token值是否正确，不正确就丢弃掉，正确就验证通过。

     （因为有些人喜欢钻牛角尖，所以再次强调下，我们习惯于区分CSRF和XSRF，后者是在XSS的情况下，防范CSRF和防范XSS是需要分开的两套防御方案）

      由于CSRF的防范原理是比对token，所以需要存在两个token用来比对，其中一个，已经下发到用户的返回页面里去了，而且是用户提交请求时候的一个必须的参数。另外一个token，一般就存在于服务器的session中；当然这样会造成依赖于session，使得在restful的架构环境下不好在不同服务期间拷贝session，所以，还有一种做法就是将token放到保存了完整session的cookie中。

      JJYY了这么多，只是简述了下anti-CSRF token的原理，在实际应用的时候，往往这个token是作为一个hidden字段加在form表单里的，或者是加在某些link里。

      姑且不讨论框架实现的问题，这个token最怕的就是泄露，XSS后之所以会让这个方案失效的原因就在于XSS可以读到这个token（tenfy:该token的部署应该是自己站点才能读取和提交，第三方站点无法读取和提交，否则该token第三方站点也可以伪造，那么依赖该token的CSRF防范措施就会失效，所以token一般不能直接使用已有的cookie，因为这样的话，第三方站点进行提交请求发动CSRF攻击，该cookie也会被浏览器自动带给目标站点，token也不能显示的写在URL链接的地方并且是多次有效的，因为这样的话，第三方站点也可以直接拷贝该token后直接赋值到第三方站点的某个URL，通过诱导用户打开某个链接而自动提交该token，但可以依赖某个salt，该salt存储在cookie，如用户登录态key等，然后在自己站点动态执行脚本，对salt进行某种算法变换成一个token，并且该token通过脚本在自己站点提交的时候动态增加该参数进行提交，这样只所以成功是因为：对第三方站点，虽然发送CSRF请求浏览器会自动通过cookie带salt过去目标站点，但第三方站点无法通过脚本读取该cookie并进行按照某种算法转换成token，另外一方面我们的token是动态在自己站点附加到提交操作的）。

      所以我们在布署CSRF token的时候，需要注意的一点，就是在一些页面里，需要慎重的加这个token，因为可能会存在其他途径，导致这个token的泄露。

     正确的做法是，将anti-CSRF Token加到form里，尽量减少加到link里的时候，重要操作都用form来完成。特别需要注意的是那些展示页面的url尽量不要加token.