非安全专家可以提前搜索阅读下面几类文章后再继续阅读

CSRF是什么？
解决CSRF几种手段对比


CSRF的token防御方案面临的问题：
1、专门一套的系统来维护token，代价较高
2、业务较多，而且涉及前端后端，全部推行阻力很大
解决办法：
针对第一个问题，我们的解决办法中，不采用维护一套专门的token服务这种办法。

导致CSRF的原因有两个，一个是浏览器只会根据数据提交的目标域来判断是否请求中带上身份验证信息（一般来说都是cookie），另一个是后台只判断用户的请求中的身份验证信息是否存在。
token解决办法是把用户的身份验证信息也放一部分到页面内容中，这部分信息就是大家经常说的token，一般来说，使用这个token我们要考虑的是：如何和特定用户一一对应，何时失效？，如何保护？

我们的办法是，这个token是cookie中的验证身份信息（session）的一个单向变形，token=md5(session),这样的话，session失效后，token也就失效。token和session是同一套机制，只要维护好session，token就自动维护好了。不增加专门的服务来维护。

针对第二个问题
    一般网站都有一个固定的header或者footer，在这个文件中加入一个全局的js变量，这个变量的值就是token，前端所有的需要做csrf的请求只要做个标记，提交的时候自动把这个token带上，就可以了。这样就避免了每个表单生成的时候就很繁琐的把token放到一个隐藏域里面去。

ps：一些get请求的CSRF临时防御办法（这个要和referer判断一起合作）
发起a.jsp?param=a的请求后，后台自动重新定向到a.jsp?param=a&token=value