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

<a href="http://blog.diniscruz.com/2011/07/finally-here-is-how-i-have-been.html">http://blog.diniscruz.com/2011/07/finally-here-is-how-i-have-been.html</a>

<a href="http://blog.diniscruz.com/2011/07/two-security-vulnerabilities-in-spring.html">http://blog.diniscruz.com/2011/07/two-security-vulnerabilities-in-spring.html</a>

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.

issue.

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

<a href="http://o2platform.wordpress.com/2011/07/11/o2-script-with-blackbox-exploits-for-spring-mvc-autobinding-vulnerabilities-in-jpetstore/">O2 Script with BlackBox exploits for Spring MVC AutoBinding vulnerabilities in JPetStore</a>

(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

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)

video) - Blop post that shows an O2 Script that starts the apache and hsqldb server

is 30Mb because it includes apache server)

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.