Security Advisory Issued for Spring MVC

Posted by Ryan Slobojan on Jul 16, 2008

Sections

Development,

Architecture & Design

Topics

Java ,

Security ,

Web Frameworks

Tags

Spring

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.

1. Back to top

   Yawn, that's nothing new!

   by Michael Mayr

   I don't see how this is news in any way. Just take a look at the spring forum. This behavior and workaround has been discussed there for 4 years (e. g. forum.springframework.org/showthread.php?t=10820). Just because some company decides to issue a press release about documented behavior of a web framework and another company then feels urged to issue a security advisory because of that doesn't make it a security discovery. And calling that it "a newly discovered class of vulnerabilities" feels completely exaggerated to me.

   Reply

2. Back to top

   Re: Yawn, that's nothing new!

   by Thomas Anderson

   Agreed. This should not be listed as security advisory.
   
   I think this is an attempt by the reporting company to increase web traffic to their website.
   
   Don't be surprised if they come out with another security advisory for windows saying
   'If you leave your laptop unattended, some one can use your laptop without your permission and delete critical windows files, and make the operating system inoperable'.

   Reply

3. Back to top

   Re: Yawn, that's nothing new!

   by Tomas Salfischberger

   It is nothing new indeed, the whole "problem" is just documented behaviour.
   
   
   
   Apart from that it is something that is sometimes overlooked, so I wrote a quick blog-post about it three months ago (Security implications of the Spring DataBinder) just to remind people about the risk.

   Reply

4. Back to top

   News Flash: Security Advisory for JSP 1.0 and later

   by Geert Pante

   After 10 years of investigation, a critical design flaw was detected in the JSP specification since version 1.0 and consequently all Java based web application servers that implement this specification. This design flaw exposes vulnerability to ModelView Injection and can lead to unauthorised access and non-verified business transactions. Yada, yada, blablabla, we're doomed!
   
   
   
   The vulnerability is exposed whenever a JSP page uses
   
   <jsp:setProperty name="mybean" property="*" />.

   Reply

• Older >