Finally ... here is how I have been analysing Spring MVC apps using O2

One of the greatest challenges I always had when reviewing Spring MVC applications, was to gain a full picture of its controllers, and more importantly its CommandClasses (i.e. the POJOs that are AutoBinded by Spring and who are a common source of high/critical vulnerabilities in Spring MVC apps).

The way I approach these problems (visualizing/understanding Spring, Struts, DWR, Sharepoint, etc...), is to write scripts that consume the Application's articfacts (web.xml, *-servlet.xml, source-code, class files) and then consolidate that information in 'easy' (or easier) to undersand visualizations.

Unfortunally most of the great examples that I had in the past were built on top of Client code, so I couldn't really share them. But finally, the O2 Scripts have reached a level of maturity that it was easy to create a generic version of them for Spring's MVC Demo application: JPetStore.

Ironically, this demo application from Spring (which is used by Spring Developers to learn how to use Spring), is actually vulnerable to a number of security issues, including some spectacular cases of the Spring MVC AutoBinding issue.

I have created a number of Blog posts and videos that hopefully will help you to understand (and replicate) the issue:

• O2 Script with BlackBox exploits for Spring MVC AutoBinding vulnerabilities in JPetStore (with video) - Blog post that shows a number of security exploits in action, for example: create a shopping cart, to though the payment process, and change the total value on the last step
• O2 Script: 'Spring MVC Util – View Controllers' (with video) - Blog post that presents a visualizer for the Spring MVC mappings. This is the most imporant script here , since this is the view that is really unique (and the one I have not seen anywhere else). What you have there is a full mapping of the Spring MVC properties for JPetStore, which includes not only the 'URL to Controller' mappings, but (much more important) a 'expanded' view of the CommandClass. And altough the JPetStore example is already quite a good one, in the real world these POJO objects tend to be massive (with cases where the developers/management only expects that only a couple fields should be populated from an HTTP request, and in reality, dozens if not hundreds of fields can be edited/manipulated)
• O2 Script for "Spring MVC JPetStore – Start Servers" (start/stop apache and hsqldb) (with video) - Blop post that shows an O2 Script that starts the apache and hsqldb server
• http://s3.amazonaws.com/Demo_Files/jPetStore%20-%20O2%20Demo%20Pack.zip - Fully packaged version of JPetStore and relevant O2 Scripts (it is 30Mb because it includes apache server)
• http://diniscruz.blogspot.com/2011/07/two-security-vulnerabilities-in-spring.html - Blog post with a couple more details about the Spring MVC AutoBinding vulnerability (exploited above) and a link to the 2008 white paper published on this topic  

The other important factor about these examples, is that I finally have a real example that can be used when talking with the Spring Framework team, other OWASP/AppSec FOSS tools and with AppSec vendors (tools and service-providers). Basically, from now on the message is: here is a complete scenario, now lets figure out how to use your technology to fix, detect or mitigate this.

This is also a part of O2 that I was waiting for, in order to be able to fully participate in the current OWASP 'reach the developer' efforts. In order to reach the developers, we need to speak their language, and with these examples (and technology) I can finally communicate properly with developers, and show them how their app works.

Note that the point here is not to push that everybody should be using using O2 to perform this type of analysis!   My objective with O2 is to show what can/should be done, and to allow others to create more native implementations of these techniques (in this case, there should be an eclipse plug-in to do this or to consume this data). Ultimately if we want to reach the developers we need to communicate with them using tools and techniques they are already used to.

There is still a lot to document and to map out (including other tools that merge even further the black-box and white box worlds), so please take these scripts for a test drive, and help me to create a really powerful 'Spring MVC Security Analsys ToolKit' that can dramatically increase the security of Spring MVC applications :)

We also need to start thinking about creating an (Open) 'Spring MVC Security Rule Pack' which can be maintained by the community and consumed by the multiple tools/services.

Final note for the .NET Crowd, the ASP.NET MVC has the same problem, and I although I have not looked at a big ASP.NET MVC app, I will bet that they will create the same types of vulnerabilties (so ...  if you have access to such an app, try the O2's ASP.NET MVC visualizer on it :)  )