Category:OWASP Security Analysis of Core J2EE Design Patterns Project/EISTier

Most if not all JEE applications require access to enterprise or business data from a persistent data store. Data, however, can reside in many different kinds of repositories, from relational databases to mainframe or legacy systems. Mixing application logic with persistence logic introduces tight coupling and creates a maintenance nightmare for an application. The Data Access Object (DAO) pattern allows for the encapsulation of all access to the persistent data store and manages connections to the data tier, while hiding the implementation details of the persistence API from the client. A DataAccessObject implements create, find, update, and delete operations.

Analysis

Avoid

Interpreter Injection

DataAccessObjects (DAOs) interact with interpreters such as SQL-enabled databases or Lightweight Directory Access Protocol (LDAP) enabled repositories. DAOs are therefore susceptible to injection-style attacks such as SQL injection. Avoid SQL attacks by using properly constructed prepared statements or stored procedures. For other interpreters, such as LDAP or XML data stores, use appropriate encoding to escape potentially malicious characters such as LDAP encoding or XML encoding. Remember to use a whitelist approach for encoding rather than a blacklist approach.

You may not find encoding methods for some interpreters, leaving your code highly susceptible to interpreter injection. In these cases use strict whitelist input validation.

Improper Resource Closing

Developers often forget to properly close resources such as database connections. Always close resources in a finally block, check for null pointers before closing on an object, and catch and handle any possible exception that may occur during resource closing within the finally block.

Unencrypted Connection String Storage

In order to communicate with a database or other backend server, most applications use a connection string that includes a user name and password. Developers often store this connection string un-encrypted in server configuration files such as server.xml. Malicious insiders and external attackers who exploit path traversal vulnerabilities may be able to use a plaintext connection string to gain unauthorized access to the database.

Encrypt database and other server credentials during storage. Unfortunately, any method you use to encrypt the connection string has weaknesses. For instance, WebLogic provides an encrypt utility to encrypt any clear text property within a configuration file, but the utility relies on an encryption key stored on the application server. Other methods, such as Jasypt’s password based encryption mechanisms require either manual intervention or remote server communication during startup to implement securely. Nevertheless, storing a password plaintext is the least secure option so always use some form of encryption.

Exposing Implementation-specific Exceptions

A DataAccessObject makes a direct connection to the persistence layer and executes queries against it, returning data to the client. Such access requires correct handling and translation of exceptions that stem from the data tier. Ensure that exceptions that are thrown from implementation-specific packages, such as java.sql.* or javax.sql.* are handled and logged appropriately in the DataAccessObject and are not simply propagated to the client. One popular strategy is to log the exception and throw a custom-made exception to the client, such as a DAOException.

In JEE applications, certain business services can involve complex processes that may consume considerable time and resources. In such cases, developers often prefer to invoke these services asynchronously. The Service Activator pattern allows for the reception of asynchronous requests from a client and invokes multiple business services. A ServiceActivator class is typically implemented as a JMS listener that receives and parses messages from the client, identifies and invokes the correct business service to process the request, and informs the client of the outcome.

Analysis

Avoid

Denial of Service in Message Queues

Attackers may fill up message queues to launch a Denial of Service (DOS) attacks. Perform a sanity check on the size of a message prior to accepting it into the message queue.

Unauthenticated Messages

Allowing unauthenticated access to BusinessServices or other middle tier components leaves applications susceptible to insider attacks. Build system-to-system authentication into the ServiceActivator itself or use container-managed mechanisms such as mutual certificate authentication.

Another approach is to add authentication credentials into each message, similar to WS-Security authentication in web services. Remember, however, that processor-intensive authentication functions may themselves leave applications vulnerable to DOS attacks.

Unauthorized Messages

BusinessServices often expose critical middle tier or backend functions. Include functional authorization checks to protect BusinessServices from authenticated user privilege escalation.

Developers sometimes skip middle tier authorization, relying instead on functional authorization checks in the presentation tier (e.g. application controller checks). A presentation-tier-only authorization approach might work with strong infrastructure-level access controls. Remember, however, that you must duplicate authorization checks on all channels that access the business service. Wherever possible use the ServiceActivator to enforce consistent access control for all messages.

Dynamic SQL in Database Response Strategy

The Database Response strategy stores the message response in a database that a client subsequently polls. As with other database interaction patterns, remember to use properly configure Prepared Statements or stored procedures to avoid SQL injection.

Unvalidated Email Addresses in Email Response Strategy

The Email Response strategy sends a message response though email. Malicious users who can influence the response may provide multiple email addresses and use the server as a gateway to send unauthorized spam messages. Use whitelist validation to ensure that users supply only one email address.

Patterns such as Data Access Object emphasize the value of separating persistence details from BusinessObjects. Some applications must also separate persistence details from the application object model. The Domain Store pattern allows for this separation, unlike container-managed persistence and bean-managed persistence strategies, which tie persistence code with the object model. The Domain Store pattern can be implemented using either a custom persistence framework or a persistence product, such as Java Data Objects.

Analysis

Avoid

Interpreter Injection

Domain Stores interact with interpreters such as SQL-enabled databases or Lightweight Directory Access Protocol (LDAP) enabled repositories. DAOs are therefore susceptible to injection-style attacks such as SQL injection. Avoid SQL attacks by using properly constructed prepared statements or stored procedures. For other interpreters, such as LDAP or XML data stores, use appropriate encoding to escape potentially malicious characters such as LDAP encoding or XML encoding. Remember to use a whitelist approach for encoding rather than a blacklist approach.

You may not find encoding methods for some interpreters, leaving your code highly susceptible to interpreter injection. In these cases use strict whitelist input validation.

Properly Close Resources

Developers often forget to properly close resources such as database connections. Always close resources in a finally block, check for null pointers before closing on an object, and catch and handle any possible exception that may occur during resource closing within the finally block.

Connection String Storage

In order to communicate with a database or other backend server, most applications use a connection string that includes a user name and password. Most developers store this connection string un-encrypted in server configuration files such as server.xml. Malicious insiders and external attackers who exploit path traversal vulnerabilities may be able to use a plaintext connection string to gain unauthorized access to the database.

Encrypt database and other server credentials during storage. Unfortunately, any method you use to encrypt the connection string has weaknesses. For instance, WebLogic provides an encrypt utility to encrypt any clear text property within a configuration file, but the utility relies on an encryption key stored on the application server. Other methods, such as Jasypt’s password based encryption mechanisms require either manual intervention or remote server communication during startup to implement securely. Nevertheless, storing a password plaintext is the least secure option so always use some form of encryption.

A web service is a popular way of exposing business services to other applications. The integration of different systems, however, can typically involve incompatibilities and complexities. Furthermore, it is desirable to limit the set of services that are exposed by an application as web services. The Web Service Broker pattern uses XML and web protocols to selectively expose and broker the services of an application. A WebServiceBroker coordinates the interaction among services, collects responses and performs transactions. It is typically exposed using a WSDL. The EndpointProcessor class is the entry point into the web service, and processes the client request. The EndpointProcessor then invokes the web service through the WebServiceBroker, which brokers to one or more services.

Analysis

Avoid

XML Denial of Service

Attackers may try Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server or an Intercepting Filter performs a sanity check on the size of the XML message prior to XML parsing or validation to prevent DOS conditions.

Disclosure of Information in SOAP Faults

One of the most common information disclosure vulnerabilities in web services is when error messages disclose full stack trace information and/or other internal details. Stack traces are often embedded in SOAP faults by default. Turn this feature off and return generic error messages to clients.

Publishing WSDL Files

Web Services Description Language (WSDL) files provide details on how to access web services and are very useful to attackers. Many SOAP frameworks publish the WSDL by default (e.g. http://url/path?WSDL). Turn this feature off.

Using DTDs

Document Type Definition (DTD) validators may be susceptible to a variety of attacks such as entity reference attacks. If possible, use XML Schema Definition (XSD) validators instead. If a DTD validator is required, ensure that the prologue of the DTD is not supplied by the message sender. Also ensure that external entity references are disabled unless absolutely necessary.

Unvalidated Input on Web Services

Web services often expose critical Enterprise Information Systems (EIS) that are vulnerable to interpreter injection attacks. Protect EIS systems at the web service level with strict input validation on all client-supplied parameters. XML encode untrusted data prior to its inclusion in a web service / XML response.

Unauthenticated and Unauthorized Web Service Requests

Like the other middle and EIS tier components, developers often employ weaker or altogether ignore authentication and authorization controls on web service requests – making web services an ideal target for attackers. Authenticate and authorize every web service request.