Ounce 实验室近日提出了与 Spring MVC 相关的两个潜在安全问题。这两个问题会影响到使用 Spring MVC 构建的应用，其产生的原因都与服务器端对客户端参数的处理有关。InfoQ 深入分析了这两个问题并与Ounce 实验室展开了一番讨论。
Ounce 实验室的官方发布中这样描述这两个问题：
这些新发现的安全漏洞和一般被跨站点脚本（cross site scripting，即 XSS）或 SQL 注入攻击利用的漏洞不同，它们并不是 Spring 框架内部的安全漏洞，而是应用设计上的问题。如果应用没有恰当的设计和实现，那么就有可能暴露自身的核心业务应用，并被攻击者利用。如果开发者在使用 Spring 框架设计和测试应用的时候头脑中能对安全问题有个清楚且正确的认识的话，企业应用在部署之后也就不会那么容易遭到攻击了。
接着，Ounce 逐一剖析了这两个漏洞：
首先涉及的是数据绑定过程。Spring MVC 有这样一个特性：可以直接将表单中提交的字段自动传递到代表对象模型的 java beans。这个特性本身没有什么问题，但当你使用同一个 bean 来维护多个表单及数据（提交这些数据的表单是不同的）时问题就产生了。举个例子，比方说你有一个代表用户账户的 bean，而你的 web 应用有两个不同的表单会更新该 bean，其中一个表单用来创建新帐户，另一个用来更新已有帐户，那么攻击者就有可能“借”更新帐户的表单的“手”去修改另一个用户的帐户。第二个安全漏洞与攻击者借助用户可管理数据来控制业务流程有关。在安全领域中，人们在用户数据的验证方面投入了很到的精力，以此来防止恶意的脚本内容或者 SQL 注入攻击，然而如果用户可管理数据可以被用来控制业务流程的话，那么这些数据也必须通过验证。再举个例子，有一个使用 Spring MVC 构建的交易应用，这个应用中有三个独立的控制器：一个处理新交易请求；另一个处理交易请求验证；还有一个处理交易执行。一旦该交易流程中存在某个点，用户在这点上能操纵控制器随意将请求发送到的非既定的“视图”，那么这个业务流程就存在被扰乱的可能。如果正常交易流程被扰乱，最后执行的则会是未经验证的交易。
SpringSource 的安全咨询部门也详细分析了这些问题并给出了修复这些问题的方案：
为了防止数据提交到不可编辑的字段的情况发生，我们应该在显示配置 DataBinder 的过程中声明允许绑定的字段，这需要设置应用中每个 DataBinder 实例的“allowedFields”属性。关于如何在主要的控制器实现中完成这些操作，可以参考下面这个例子：为了避免ModelView 注入的发生，千万不要让客户端自行选择视图。视图的选择应当由服务器端来决定。
- SimpleFormController——覆写 initBinder(HttpServletRequest, ServletRequestDataBinder) 方法，并调用 ServletRequestDataBinder 实例的 setAllowedFields(String[]) 方法
- MultiActionController——在处理器的方法体中调用你创建的任何 ServltRequestDataBinder 实例的 setAllowedFields 方法
- @Controller——使用 @InitBinder 注解将 WebDataBinder 显式注入到配置它的方法中。调用 setAllowedFields(String []) 方法限制该控制器类所允许的属性。如果各个处理方法对应不同的 allowedFields 值的话，可以通过 @InitBinder 注解的方法接收 HttpServletRequest，并取消当前的请求映射
- AbstractWizardFormController——覆写 initBinder(HttpServletRequest, ServletRequestDataBinder) 并调用 DataBinder 实例的 setAllowedFields(String[]) 方法。调用 getCurrentPage(HttpServletRequest) 方法以配置每个页面允许的属性集
Ounce 又说他们相信其它很多框架也面临着类似的风险：
只要框架允许自动绑定或者用户可以控制应用的业务处理，那么应用都有可能存在上面提到的两个问题。我在客户编写的框架中就看到了类似的漏洞，在最近关注的一个 Ruby on Rails 应用中，也发现了同样的问题。产生这些问题的原因在于，设计这些框架的初衷是简化应用的开发，帮助开发者减少代码的编写量。但如果这些框架无法让简单和安全（框架默认的设置环境所保证的安全）齐头并进的话，我们最后得到的将是大量容易编写但并不安全的应用。
注册/登录 InfoQ 发表评论