Spring MVC 3.0 MVC Binding rules

Following the work done on the O2 Cmd - Spring MVC module and the conversations we had at OWASP AppSec Ireland about the security implications of the Spring Framework MVC, I spent some time today looking at what is happening at its next major release (3.0.x)

From the MVC documentation section 15.3.2.3 Supported handler method arguments and return types section in Spring 3.0 (see 15.3 Implementing Controllers ) we can see (included at the end of this post) the Spring MVC rules to:

a) map web data into controllers and

b) send data from controllers to the views.

There are quite a number of new features/capabilities, and most have security implications!

For reference, here are a number of good articles & Blog Posts on Spring MVC 3.0

• Spring Finance > Part 2: Spring @MVC & Spring 3.0 REST integration
• New stuff in Spring 3.0 & New stuff in Spring 3.0, part 2
• REST in Spring 3: @MVC
• Spring 3 MVC CodeMash 2009
• Spring 3.0 docs: 2.5 Overview of new features , 15.3 Implementing Controllers
• GWT, Spring 3.0 MVC, and REST on Google App Engine / Java - Part 1 & GWT, Spring 3.0 MVC, and REST on Google App Engine / Java - Part 2

I find a bit worrying that the security implications of the way Spring MVC works (for both old and new features) is NOT properly documented in these articles (for example making references to Security implications of the Spring DataBinder (note-to-self: create page with my & others past research on this topic))

The list below (from 15.3 Implementing Controllers) is what we need to add to the next version of O2 Cmd - Spring MVC module so that it supports Spring MVC 3.0 (in fact I need to dig out the docs about Spring MVC 2.5 works, and start there :) )

15.3.2.3 Supported handler method arguments and return types

Handler methods that are annotated with @RequestMapping can have very flexible signatures. They may have arguments of the following types, in arbitrary order. (except for validation results, which need to follow right after the corresponding command object, if desired):

• Request and/or response objects (Servlet API). Choose any specific request/response type, for example, ServletRequest / HttpServletRequest.
• Session object (Servlet API): of type HttpSession. An argument of this type enforces the presence of a corresponding session. As a consequence, such an argument is never null.
• org.springframework.web.context.request.WebRequest or org.springframework.web.context.request.NativeWebRequest. Allows for generic request parameter access as well as request/session attribute access, without ties to the native Servlet/Portlet API.
• java.util.Locale for the current request locale, determined by the most specific locale resolver available, in effect, the configured LocaleResolver in a Servlet environment.
• java.io.InputStream / java.io.Reader for access to the request's content. This value is the raw InputStream/Reader as exposed by the Servlet API.
• java.io.OutputStream / java.io.Writer for generating the response's content. This value is the raw OutputStream/Writer as exposed by the Servlet API.
• @PathVariabe annotated parameters for access to URI template variables. See Section 15.3.2.1, “URI Templates”.
• @RequestParam annotated parameters for access to specific Servlet request parameters. Parameter values are converted to the declared method argument type. See Section 15.3.2.4, “Binding request parameters to method parameters with @RequestParam”.
• @RequestHeader annotated parameters for access to specific Servlet request HTTP headers. Parameter values are converted to the declared method argument type.
• @RequestBody annotated parameters for access to the request HTTP body. Parameter values are converted to the declared method argument type using HttpMessageConverters. See Section 15.3.2.5, “Mapping the request body with the @RequestBody annotation”.
• java.util.Map / org.springframework.ui.Model / org.springframework.ui.ModelMap for enriching the implicit model that is exposed to the web view.
• Command or form objects to bind parameters to: as bean properties or fields, with customizable type conversion, depending on @InitBinder methods and/or the HandlerAdapter configuration. See thewebBindingInitializer property on AnnotationMethodHandlerAdapter. Such command objects along with their validation results will be exposed as model attributes by default., using the non-qualified command class name in property notation. For example, "orderAddress" for type "mypackage.OrderAddress". Specify a parameter-level ModelAttribute annotation for declaring a specific model attribute name.
• org.springframework.validation.Errors / org.springframework.validation.BindingResult validation results for a preceding command or form object (the immediately preceding argument).
• org.springframework.web.bind.support.SessionStatus status handle for marking form processing as complete, which triggers the cleanup of session attributes that have been indicated by the@SessionAttributes annotation at the handler type level.

The following return types are supported for handler methods:

• A ModelAndView object, with the model implicitly enriched with command objects and the results of @ModelAttribute annotated reference data accessor methods.
• A Model object, with the view name implicitly determined through a RequestToViewNameTranslator and the model implicitly enriched with command objects and the results of @ModelAttributeannotated reference data accessor methods.
• A Map object for exposing a model, with the view name implicitly determined through a RequestToViewNameTranslator and the model implicitly enriched with command objects and the results of@ModelAttribute annotated reference data accessor methods.
• A View object, with the model implicitly determined through command objects and @ModelAttribute annotated reference data accessor methods. The handler method may also programmatically enrich the model by declaring a Model argument (see above).
• A String value that is interpreted as the view name, with the model implicitly determined through command objects and @ModelAttribute annotated reference data accessor methods. The handler method may also programmatically enrich the model by declaring a Model argument (see above).
• void if the method handles the response itself (by writing the response content directly, declaring an argument of type ServletResponse / HttpServletResponse for that purpose) or if the view name is supposed to be implicitly determined through a RequestToViewNameTranslator (not declaring a response argument in the handler method signature).
• If the method is annotated with @ResponseBody, the return type is written to the response HTTP body. The return value will be converted to the declared method argument type usingHttpMessageConverters. See Section 15.3.2.6, “Mapping the response body with the @ResponseBody annotation”.
• Any other return type is considered as single model attribute to be exposed to the view, using the attribute name specified through @ModelAttribute at the method level (or the default attribute name based on the return type class name). The model is implicitly enriched with command objects and the results of @ModelAttribute annotated reference data accessor methods.