CSRF防御方案：

　　（1）在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。

　　（2）在form表单中自动填入token字段，比如value="$token" />。

　　（3）在Ajax请求中自动添加token，这可能需要已有的Ajax封装实现的支持。

　　（4）在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击。

　
　　注意：

　　在Spring MVC以及一些其他的流行Web框架中，并没有直接提供针对CSRF的保护，因此这些功能需要自己实现。

　　因此，对于框架来说，管理好跳转目的地址是很有必要的。一般来说，可以在两个地方做这件事情：

　　（1）如 果Web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中；

　　（2）另一种解决方式是控制HTTP的Location字段，限制Location的值只能是哪些地址，也能起到同样的效果，其本质还是白名单。

　　有很多与安全相关的Headers，也可以统一在Web框架中配置。比如用来对抗ClickJacking的X-Frame-Options，需要在页面的HTTP Response中添加：X-Frame-Options： SAMEORIGIN

　Web框架可以封装此功能，并提供页面配置。该HTTP头有三个可选的值：SAMEORIGIN、DENY、ALLOW-FROM origin，适用于各种不同的场景。

　　在前面的章节中，还曾提到Cookie的HttpOnly Flag，它能告诉浏览器不要让JavaScript访问该Cookie，在Session劫持等问题上有着积极的意义，而且成本非常小。但并不是所有的Web服务器、Web容器、脚本语言提供的API都支持设置HttpOnly Cookie，所以很多时候需要由框架实现一个功能：对所有的Cookie默认添加HttpOnly，不需要此功能的Cookie则单独在配置文件中列出。这将是非常有用的一项安全措施，在框架中实现的好处就是不用担心会有遗漏。就HttpOnly Cookie来说，它要求在所有服务器端设置该Cookie的地方都必须加上，这可能意味着很多不同的业务和页面，只要一个地方有遗漏，就会成为短板。当网站的业务复杂时，登录入口可能就有数十个，兼顾所有Set-Cookie页面会非常麻烦，因此在框架中解决将成为最好的方案。

　　一般来说，框架会提供一个统一的设置Cookie函数，HttpOnly的功能可以在此函数中实现；如果没有这样的函数，则需要统一在HTTP返回头中配置实现。

　　Spring Security为Spring MVC的用户提供了许多安全功能，比如基于URL的访问控制、加密方法、证书支持、OpenID支持等。但Spring Security尚缺乏诸如XSS、CSRF等问题的解决方案。