Security Vulnerabilities with JPetStore and visualization of the AutoBinding Issues

Hi, I just posted the following blog post (Finally... here is how I have been analysing Spring MVC apps using O2) which contains details about:

• a tool to exploit a number of vulnerabilities in the JPetStore application (from the browser)
• a tool to exploit a number of vulnerabilities in the JPetStore application (from the browser)
• a tool to visualize the Spring MVC mappings (URLs, Controllers and CommandClass) using static analysis
• a tool to automatically start and stop the JPetStore
• link to a research paper I co-wrote in 2008 that talks about this problem

I would like to stress that every single security review that I have done on Spring MVC-based applications in the last couple years had high/critical vulnerabilities created by the Spring AutoBinding, so I really would like to start a dialog on how to come up with solutions to help developers.

For example, on my last security engagement, we ended up using a solution based on 'wrapper classes with only setters for the AutoBinding' which proved to be a much better solution than using the *AllowedFields solution. I would like to explore this further, and see if we can come up with a more 'native' solution.

I also would like to get the Spring Mappings direcly from the Spring engine and not have to perform the type of analysis that I'm currently doing with OWASP O2 Platform.

If my blog post on this topic is too big to consume originally, you might want to start with these videos:

JpetStore - View Spring MVC Controllers and CommandClasses

http://www.youtube.com/watch?v=ZQd7xqAlSRc

JpetStore - BlackBox Exploits

http://www.youtube.com/watch?v=yzTExpNZ2bw

JpetStore - Start Server and Make sure everything is working

http://www.youtube.com/watch?v=8Y_zvzLGNtg

Let me know what you think about these techniques, and what should be the next steps

Thanks

Dinis Cruz

I suggest creating a JIRA issue which links back to this post. That way it is in the official repository also..

Quote:

---

For example, on my last security engagement, we ended up using a solution based on 'wrapper classes with only setters for the AutoBinding'

---

I think having a dedicated presentation-layer "form model" where there is a one-to-one correspondence between a form backing object and a set of allowed request parameters almost inevitably ends up being a good idea. And by definition it avoids exposing fields to auto-binding that shouldn't be. While this seems like extra work at first, in many applications the needs of the user interface inevitably differ ever so slightly (or not so slightly) from the needs of the domain model. Form model objects become a good place to encapsulate UI-specific logic. Of course each application is free to choose from a range of options.

When web application security is concerned, there is a wide range of concerns to consider. Using a framework like HDIV can help address many of them at once including data integrity and auto-binding.

Yes, I completely agree Rossen, that 'separation of duties' is absolutely critical to make sure these type of security vulnerabilities don't happen. One of my key focus in on finding ways to visualize the current mappings and help the developer teams to understand how their (complex) app actually works :)

I posted earlier today a couple more blog posts with more code samples and vulnerabilities, see Couple more blog posts on JPetStore and additional Spring MVC Autobinding vulnerabilities

Also I'm going to do a couple webcasts in the next days, and it would be great if you could join and share your experiences: Webcast: "Analysing a Spring MVC App (JPetStore) using the OWASP O2 Platform"

In my opinion a solution based on "form models" is a valid solution but it is not an effective solution in practice and doesn't follow Spring's philosophy: reduce Java complexity (automating the programmer's job).

This kind of solutions, hand-coded solutions delegated to developers, reminds me the times when we managed JDBC connections by hand. At that time people knew they had to close JDBC connections but always there were cases where someone forgot to close a connection.

Thanks to Spring (SpringJDBC for example), we don't manage JDBC connections (getConnection, closeConnection) by hand any more, and today we never have this kind of problems. In this case the architecture (Spring JDBC) implements the rule automatically and at the same time, we reduce the developer's work.

It's important to note that most web application developers usually don't know about these kind of web vulnerabilities.

I think we should follow Spring's philosophy in order to solve all web vulnerabilities (not only auto binding vulnerability).

How can we solve some of the most important web vulnerabilities automatically?

Many of these vulnerabilities have the same source, users can but they shouldn't:
- Update a parameter value (for example a parameter included within a link,
hidden parameter,..)
- Add a new parameter
- Request an unexpected url
- Update a cookie
-....

In other words, users should edit only editable data (textbox and textarea data) but they can edit and create all kind of data.

This reality creates a big problem for the developers because they must validate all request data by hand, programatically.

At the same time we have another big problem, many developers don't know these web vulnerabilities.

How can we avoid this problem? How can we validate a web request automatically without developers intervention?

Using the programming model offered by Spring MVC (or other web frameworks) developers tell us very important information through web frameworks's tags. In other words, custom tags generate all parameters and urls sent to the client.

If we store this data on the server (for example within HttpSession) and extending web frameworks's tags functionality we can validate a request automatically (some of the most important vulnerabilities). We can validate a request using the data we have stored before.

We have implemented this idea or pattern in HDIV project. HDIV extends Spring MVC, JSF 1, JSF 2, Struts 2, Struts 1, custom tags functionality in order to implement automatically some of the most important security validations.

This idea follows Spring's Philosophy and at the same time the most important security pattern: security by default. It's important to note that HDIV doesn't change Spring MVC programming model and it's applied declaratively using Spring's configuration.

Of course, there are validations like editable data validations (textbox and textare data) that we will have to validate by hand (using whitelists as much as possible) but we can't automatize totally this kind of validations because depends on the application.

In this kind of validations HDIV offers a generic editable validations module that offers a generic validation system for all editable data (data generated on textbox and textarea components).

Regards,

Roberto Velasco