This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Security Vulnerabilities with JPetStore and visualization of the AutoBinding IssuesPage Title Module

Security Vulnerabilities with JPetStore and visualization of the AutoBinding Issues

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.

Comment

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.

Comment

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

Comment

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