Tuesday 12 July 2011

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:
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 :)  )