CSRF防御方案:---基于《白帽子讲Web安全 》

CSRF防御方案:


(1)在Session中绑定token。如果不能保存到服务器端Session中,则可以替代为保存到

Cookie里。

(2)在form表单中自动填入token字段,比如  <input type=hidden name="anti_csrf_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等问题的解

决方案。


本文出自 “丑小鸭的天空” 博客,谢绝转载!

CSRF防御方案:---基于《白帽子讲Web安全 》,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。