BT

Security Advisory Issued for Spring MVC

| by Ryan Slobojan Follow 0 Followers on Jul 16, 2008. Estimated reading time: 3 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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'.

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.

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="*" />.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT