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

防范CSRF攻击的方案有许多种，有用验证码来防的，更多的是生成一个随机的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。

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


比如，可以想象到的一种获取token的方式，就是利用referer，读出url里包含的token值（假设token已经加在url里了）。

比较简单实现就是在类似站内信的页面里插入一张图片:



这样就会在 的webserver里留下一条web日志，其中记录着该请求的referer，如果该地址正好包含了 token，那token就会泄露了。

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