Security Advisory Issued for Spring MVC

A security advisory was issued today regarding two potential Spring MVC issues which may affect applications that have been implemented using Spring MVC, both of which deal with the server-side processing of client-side parameters. InfoQ analyzed this issue in detail and spoke with Ounce Labs, which identified these issues.

The official press release described these issues as:

Unlike common application vulnerabilities that can expose Web applications to cross site scripting (XSS) or SQL injection attacks, these newly discovered class of vulnerabilities are not security flaws within the Framework, but are actually design issues that if not implemented properly expose business critical applications to attacks. The right security awareness in the design and testing phase of applications using the Framework can protect enterprises from exploitation after deployment.

Ounce then explained the issues in more detail:

The first deals with a process known as data binding. The Spring MVC includes a feature that allows for the automatic setting of form field submissions directly to java beans that represent the underlying object model. The problem is created when you are using the same bean to back multiple forms and the data that is submitted by each form is different. An example would be a bean used to represent a user’s account, if a web application has two different forms that update this bean, one for new account creation and another for existing account updates than it may be possible to use the account update form to modify the data for another user’s account. The second vulnerability has to do with using user-controllable data to control a business process. A lot of attention in the security world has been focused on validating user data for malicious script content or for SQL injection style of attacks, but any user-controllable data needs to be also validated if it is used to control a business process. Let’s say you have a trading application built using Spring MVC and you have three separate controllers, a main controller to handle new trade requests, a controller to handle trade request validation and a controller to handle the execution of the trade. If, along any point of this transaction, the user is given the ability to control the “View” the controller that forwards the request to, you can subvert a business process and, in this case, execute non-verified trades.

The SpringSource security advisory also described these issues in detail, and explained how to fix both issues:

To prevent the Data Submission to Non-Editable Fields issue from occurring, the DataBinder should be configured explicitly with the set of fields that are allowed for binding. To do this, set the "allowedFields" property on each DataBinder instance you work with in your application. Below is an example of how to do this with each major Controller implementation:

• SimpleFormController - Override initBinder(HttpServletRequest, ServletRequestDataBinder) and call setAllowedFields(String[]) on the provided ServletRequestDataBinder instance
• MultiActionController - Call setAllowedFields on any ServltRequestDataBinder instance you instantiate locally within a handler method body
• @Controller - Use the @InitBinder annotation to inject a WebDataBinder into a method used to configure it explicitly. Call setAllowedFields(String []) to restrict the fields allowed for that Controller class. If the set of allowedFields needs to vary per handler method, have your @InitBinder method accept a HttpServletRequest and key off the current request mapping
• AbstractWizardFormController - Override initBinder(HttpServletRequest, ServletRequestDataBinder) and call setAllowedFields(String[]) on the provided DataBinder instance. Call getCurrentPage(HttpServletRequest) to configure the set of allowed fields per page

To prevent the ModelView Injection issue from occurring, simply never allow the client to select the view name. View name selection is a server-side responsibility.

Ounce also said that they believed that there may be other frameworks which are at risk from similar issues:

This type of vulnerability exists in all frameworks that allow auto-binding, or where the user can control the business process of the application. I have seen this same type of vulnerability in custom written frameworks and was recently looking at a Ruby on Rails application and the same type of vulnerability can exist in these frameworks as well. The problem is that a lot of these frameworks were built with the intention of making things easy for the developer without having to write a lot of code. Unless the framework is built to make things both easy and secure (by default), we are left with a lot of insecure applications that are even easier to write.