JDOSecure Demonstration Site

| | Demonstration

Caution: The original JDOSecure demonstration website at
projekt-jdo.uni-mannheim.de is not longer available.
This is just a copy with limited functionality.

The Java Data Objects (JDO) specification is designed as a lightweight persistence approach. Thus, JDO neither supports user authentication nor role-based authorization. Consequently, users are able to query the entire data store as well as to delete persistent objects without any restriction. The novel security approach JDOSecure was developed in order to prevent unauthorized access to the data store while using the JDO-API. Based on the dynamic proxy approach, JDOSecure introduces role-based permissions to JDO-based applications.

On this website we will demonstrate the benefits of the JDOSecure architecture based on a simple web application for a car rental company. The application is implemented by using the Java Servlet technology and JDO as persistence layer. We provide two versions of this application. The first one implements JDO directly without any security enhancements. The second approach uses JDOSecure to prevent adequate security and vulnerability issues.

Example 1 - without JDOSecure: Screenshot 1
Example 2 - including JDOSecure: Screenshot 2

About the Demo Application:

The car rental application mentioned above is intended to serve as proof of concept for JDOSecure. It consists of four Java classes representing the car rental domain (cf. Figure 1): In this model, a Customer has to use his CreditCard to make a Reservation. A Reservation is always associated within exactly one vehicle (Car) and is initiated by one Customer.

The business logic was developed as a straightforward web application based on the Java Servlet technology. A Java Servlet receives browser requests and sends a response back to the client. In this scenario, the business logic consists of five Java Servlets. They all use a HttpSession in order to identify a customer and to store the arguments being entered by the user. Each website a user could visit is represented by another Java Servlet class. The arguments a user entered in a form are passed through a Servlet by attaching the information to the end of the URL after a question mark. For example, the URL


https://projekt-jdo.uni-mannheim.de/ car/showdetails?type=Car&filter=carID&value=3

is mapped to the ShowDetails Servlet and passes three arguments (type, filter, and value) to this class.

The persistence mechanism is implemented by using the Java Data Objects-Specification. Since JDO proposes the concept of transparent persistence, it allows persisting pure "Plain Old Java Objects" (POJOs). After using a JDO enhancer, the classes of the car rental domain could be stored directly by using the JDO-API.

Figure 1: UML Class Diagram describing the Car Rental Domain

Security Issues in the First Example:

When analyzing the first example, a costumer could request a list of all available cars by clicking on the "Find the best rates" button. The system will provide a table including all available cars and some useful information like the car type, the price per day, and a link to receive more details about a specific car. By following such a link, the system calls a Java Servlet (ShowDetails) by passing the according arguments like the car-ID. This class is implemented in a generic way, so that it allows to receive detailed information of different classes (e.g. a motorbike instead of a car):


Class c = Class.forName("example."+type);

Extent ext = pm.getExtent(c, false);

Query q = pm.newQuery(ext);

q.setFilter(filter+"==\""+value+"\"");

Collection col = (Collection) q.execute();

Even the generic functionality appears as a highly flexible and sophisticated approach at first glance, it unfortunately poses a major security threat as it turns out. As an example, just take a closer look to this link:


https://projekt-jdo.uni-mannheim.de/car/showdetails?type=Car&filter=carID&value=3

. The website presents some information about the car and appears rather inconspicuous. But by manipulating the arguments and changing the "Car" to "CreditCard" the security problem becomes obvious. After a few tries, someone can find the appropriate arguments to receive some credit card information for illegal use: https://projekt-jdo.uni-mannheim.de/car/showdetails?type=CreditCard& filter=creditCardType&value=visa. Even if it is simply possible to rewrite the application code in the ShowDetails class to prevent the access to the credit card information, it demonstrates unequivocally that JDO doesn't prevent unauthorized access to the data store in case of flawed applications.

How does JDOSecure Prevent Security and Vulnerability Issues in the Second Example?

JDOSecure allows to control the access to store, query, update and delete persistent objects when using the JDO-API. It introduces a fine grained access control mechanism to the JDO persistence layer and allows the definition of role-based permissions. In the second example, we have defined a "webuser" role with the following permissions:

`Permission`	`Class`
`JDOMakePersistentPermission`	`*`
`JDOQueryPermission`	`exmaple.Car`
`JDOQueryPermission`	`exmaple.Reservation`

Because we encapsulated the construction of the PersistenceManagerFactory instance in a separate method, we had to modify only one single line of source code to benefit from the security advantages. We just had to replace JDOHelper.getPersistenceManagerFactory(props) by JDOSecureHelper.getPersistenceManagerFactory(props) and of course modify the path to the libraries and configuration files. That's all.

Now, try the same link as presented in the first example: https://projekt-jdo.uni-mannheim.de/carsecure/showdetails?type=CreditCard &filter=creditCardType&value=visa. By clicking on this link, you will receive an "Access denied" message, because we are catching the java.security.AccessControlException appropriately. In the tomcat catalina.out logfile (cf. Figure 2) there is further useful information available:

INFO: Server startup in 10237 ms Initializing JDOPolicyOX... JDOSecure: Authentication succeeded for user 'webuser'. authentication succeeded Authenticated user has the following Principals: 'JDOUser: webuser' java.security.AccessControlException: access denied (de.unimannheim.wifo.jdosecure.permissions.JDOQueryPermission example.CreditCard)

Figure 2: Tomcat Logfile-Snippet

Analyze the full catalina.out file.