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

Middle and Integration Tier Security

The majority of Open Web Application Security Project (OWASP) Top 10 vulnerabilities occur in the presentation tier. While attacks do exploit vulnerabilities in the business and enterprise integration tiers, the attacks typically originate from presentation tier web pages. For example, a SQL injection payload is usually delivered as part of an HTTP request to a web page, but the exploit itself usually occurs in the integration tier.

We examine the business and integration tier patterns for security from two perspectives:

1. Attacks originating from the presentation tier, such as a Cross-Site Scripting (XSS) attack sent by a malicious web client
2. Attacks originating from the business and integration tiers, such as an unauthorized web service request to an integration tier device

The second perspective is important enough to warrant special attention. Many organizations ignore attacks originating from within the internal network. Unfortunately, the notion that organizations can completely trust insiders is flawed.In application security, developers sometimes argue that the process of launching an attack in the business or integration tiers is complicated and therefore less likely. As organizations increasingly adopt Service Oriented Architectures (SOA) in business and integration tiers with standards like Simple Object Access Protocol (SOAP) and Representation State Transfer (REST), security tools targeting these protocols are becoming readily available .

Even if you have not yet experienced an insider security incident, remember that insider attacks are on the rise and the systems you architect today may remain in production for years or even decades to come. Create secure applications by building-in protection from insider threats.

Business Delegate

The Business Delegate serves as an abstraction of the business service classes of the business tier from the client tier. Implementing a business delegate effectively reduces the coupling between the client tier and business tier, and allows for greater flexibility and maintainability of the application code. The most significant benefit of this pattern is the capability to hide potentially sensitive implementation details of the business services from the calling client tier. Furthermore, a business delegate can effectively handle business tier exceptions (such as java.rmi.Remote exceptions) and translate them into more meaningful, application-level exceptions to be forwarded to the client.

Analysis

Use to Implement

Whitelist input validation

The DelegateProxyStrategy uses BusinessDelegate objects as simple proxies to underlying services. Each BusinessDelegate is business context specific and is therefore a good place to implement whitelist security input validation. Remember, however, that BusinessDelegate validation only applies to input originating from the presentation tier. You need to duplicate input validation functionality for all other channels that access the same business tier, such as web services.

Exception Handling

A property of sound exception management is the practice of throwing an exception that is meaningful to the target tier. For example, a JMSException caught by a business tier object should not be propagated to the client tier. Instead, a custom, application-level, exception should be sent to the client tier. BusinessDelegate can effectively perform this translation, intercepting service-level exceptions from the business tier and throwing application-level exceptions to the client tier. This practice helps protect implementation-level details of the business services from calling clients. Note that exceptions can occur within and across many tiers, and restricting exception handling logic to the BusinessDelegate alone is insufficient.

Service Locator

JEE application modules from the client tier often need to access business or integration tier services, such as JMS components, EJB components, or data sources. These components are typically housed in a central registry. In order to communicate with this registry, the client uses the Java Naming and Directory Interface (JNDI) API to obtain an InitialContext object containing the desired object name. Unfortunately, this process can be repeated across several clients, increasing complexity and decreasing performance. The Service Locator pattern implements a ServiceLocator singleton class that encapsulates API lookups and lookup complexities, and provides an easy-to-use interface for the client tier. This pattern helps promote reuse of resource-intensive lookups, and decouples the client tier from the underlying lookup implementation details.

Analysis

Avoid

Memory Leaks in Caching

Developers typically use caching to improve performance. If you are not careful about implementing caching, however, you can actually degrade performance over time.

Many developers use collections like HashMaps to maintain references to cached objects. Suppose you maintain a cache using a HashMap where the keys are Strings describing services in the ServiceLocator and the values are Target objects. After a period of inactivity you want to remove the Target reference to free memory. Simply running a method like close() on the Target object will not actually make the object eligible for garbage collection because the cache HashMap still maintains a pointer to the Target object. You must remember to remove references from the HashMap otherwise you will experience memory degradation overtime and possibly suffer from Denial of Service (DoS) conditions.

Use a WeakHashMap or another collection of WeakReferences or SoftReferences rather than traditional collections to maintain caches. A WeakHashMap maintains WeakReferences to key and value objects, meaning the cache will allow key and value objects to be eligible for garbage collection. Using WeakReferences allows the garbage collector to automatically remove objects from the cache when necessary, as long as the application does not maintain any strong references (i.e. regular pointers) to the object.

If you cannot use WeakReferences or SoftReferences then ensure you regularly remove objects from the cache.

Open Access to UDDI

Many developers opt to use web services instead of more traditional middle tier technologies like Enterprise Java Beans (EJBs). In Service Oriented Architecture (SOAs), Universal Description, Discovery and Integration (UDDI), registries often play the role of Service Locator. UDDIs are extremely valuable to attackers since they house Web Service Definition Language (WSDL) files that provide blueprints of how and where to access web services. If you use UDDI, ensure that only authorized users can access registries. Consider using mutual certificate authentication with each UDDI request. Also ensure that an authenticated user is actually authorized to access specific parts of the registry.

Session Façade

Business components in JEE applications often interact with many different services, each of which may involve complex processes. Exposing these components directly to the client tier is undesirable, as this leads to a tight coupling between the client and business tiers, and can lead to code duplication. The Session Façade pattern is used to encapsulate the services of the business tier and acts as an interface to the client. Developers typically implement a SessionFacade class as a session bean and expose only the interfaces that clients require, hiding the complex interdependencies between BusinessObjects. Very little or no business logic should be placed within a SessionFacade.

Analysis

Avoid

Unauthenticated Client Calls

Allowing unauthenticated access to Enterprise Java Beans (EJBs), web services, or other middle tier components leaves applications susceptible to insider attacks. In some cases, developers configure application servers to allow open access to the underlying DataSources such as databases. Build system-to-system authentication into the Session Façade itself or use container-managed mechanisms such as mutual certificate authentication. Maybe also mention that DataSources can be made available by app servers for anyone on the network to retrieve.

Deserializing Objects from Untrusted Sources

Developers often use Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP) to communicate between the presentation and business tiers. RMI uses Java serialization and deserialization to transfer objects over the network. Treat deserialization as a dangerous function because some Java Virtual Machines are vulnerable to Denial Of Service (DOS) conditions when attackers transmit specially crafted serialized objects. Remember to treat client or third party-supplied serialized objects as untrusted input; malicious users can modify the serialized version of an object to inject malicious data or even supply objects running malicious code

Decrease the risk of a DOS attack by authenticating requests prior to deserializing data. Also upgrade and patch Java Virtual Machines just like other critical software components such as operating systems.

Use to Implement

Middle Tier Authorization at Session Facade

Session Façades are entry points to the middle tier, meaning they are ideal for handling middle-tier authorization. Ensure clients have sufficient privileges to access any function exposed through Session Façades.

Application Service

While the Session Façade pattern allows for the decoupling of the client tier from the business tier and encapsulates the services of the business tier, SessionFacade objects should not encapsulate business logic. An application may contain multiple BusinessObjects (see the next pattern) that perform distinct services, but placing the business logic here introduces coupling between BusinessObjects. The Application Service pattern provides a uniform service layer for the client. An ApplicationService class acts as a central location to implement business logic that encapsulates a specific business service of the application and reduces coupling between BusinessObjects. The ApplicationService object can implement common logic acting on different BusinessObjects, implement use case-specific business logic, invoke business methods in a BusinessObject, or methods in other ApplicationServices. An ApplicationService is commonly implemented as a plain-old Java object (POJO).

Analysis

Unauthenticated Client Calls

Allowing unauthenticated access to Enterprise Java Beans (EJBs), web services, or other middle tier components leaves applications susceptible to insider attacks. Build system-to-system authentication into the Application Service itself or use container-managed mechanisms such as mutual certificate authentication.

Business Object

Ideally, a multi-tiered application is decoupled into presentation, business and data tiers. Of the three, the business tier often results in duplicated code and tight coupling with data logic. The Business Object pattern allows for the separation of the business state and behavior from the rest of the application, and the centralization of both. BusinessObjects encapsulate the core business data, and implement the desired business behavior, all while separating persistence logic from the business logic. Using this pattern, the client interacts directly with a BusinessObject that will delegate behavior to one or more business entities, and manage its own persistence logic using a desired persistence strategy, such as POJOs or EJB entity beans.

Analysis

General Notes

In most cases, Business Objects do not implement common security features such as authentication and authorization, data validation and encoding, or session management. Ideally, a Business Object should simply provide accessor methods and offer basic business logic functions. You still need to develop with standard secure coding practices such as error handling and logging.

Composite Entity

Business Objects separate business logic and business data. While Enterprise Java Beans (EJB) entity beans are one way to implement Business Objects, they come with complexity and network overhead. The Composite Entity pattern uses both local entity beans and Plain Old Java Objects (POJOs) to implement persistent Business Objects. The Composite Entity can aggregate a single BusinessObject and its related dependant BusinessObjects into coarse-grained entity beans. Using this pattern allows developers to leverage the EJB architecture, such as container-managed transactions, security, and persistence.

Analysis

General Notes

Entity Bean Alternatives

With the rise of third party persistence frameworks such as Hibernate and IBATIS, fewer developers use entity beans. In general, application developers can take security advice for Composite Entity and apply it to persistence frameworks other than Entity Beans.

Avoid

Interpreter Injection

If you use bean managed persistence (BMP) with entity beans, then protect against injection attacks by using secure prepared statements, stored procedures, or appropriate encoding for non-database persistence mechanisms such as XML encoding for creating XML documents.

In most cases persistence frameworks like Hibernate automatically protect against SQL injection. Remember, however, that many persistence frameworks allow you to create custom queries through special functions like Hibernate Query Language (HQL). If you dynamically concatenate strings to create custom queries, then your application may be vulnerable to injection despite the fact that you use a persistence framework.

Plaintext Transmission of Confidential Data

The Composite Transfer Object strategy creates a TransferObject to send to a remote client. Many organizations do not use encrypted communication channels within the internal network, so a malicious insider attacker might sniff confidential data within a TransferObject during transmission. Either do not serialize confidential variables or use an encrypted communication channel like Secure Socket Layer (SSL) during transmission.

Transfer Object

Integration patterns such as Session Façade and Business Object often need to return data to the client. A client, however, may potentially call several getter methods on these objects, and when these patterns are implemented as remote enterprise beans, a significant network overhead is incurred with each call. The Transfer Object pattern is designed to optimize the transfer of data to the client tier. A TransferObject encapsulates all data elements within a single structure and returns this structure to the calling client. The Transfer Object pattern serves to reduce network traffic, transfer bulk data with far fewer remote calls, and promote code reuse.

Analysis

Avoid

Plaintext Transmission of Confidential Data

Many organizations do not use encrypted communication channels within the internal network, so a malicious insider attacker might sniff confidential data within a TransferObject during transmission. Either do not serialize confidential variables or use an encrypted communication channel like Secure Socket Layer (SSL) during transmission.

Transfer Object Assembler

Clients often need to access business data from potentially many different BusinessObjects, TransferObjects, or ApplicationServices to perform processing. Direct access to these different components by the client can lead to tight coupling between tiers and code duplication. The Transfer Object Assembler pattern provides an efficient way to collect multiple Transfer Objects across different business components and return the information to the client. Think of Transfer Object Assembler as a factory to create Transfer Objects. The client invokes the TransferObjectAssembler, which retrieves and processes different TransferObjects from the business tier, constructs a composite TransferObject known as the ApplicationModel, and returns the ApplicationModel to the client. Note that the client uses the ApplicationModel for read-only purposes, and does not modify any data contained within it.

Analysis

Unauthenticated Client Calls

Allowing unauthenticated access to TransferObjectAssemblers or other middle tier components leaves applications susceptible to insider attacks. If you expose your TransferObjectAssemblers directly to clients, then build in system-to-system authentication or use container-managed mechanisms such as mutual certificate authentication.

Value List Handler

Searching is a common operation in JEE applications. A search typically is initiated by the client tier and execution by the business tier. More concretely, this can involve several invocations of entity bean finder methods or DataAccessObjects by the client, particularly if the result set of the search is large. This introduces network overhead. The Value List Handler pattern affords efficient searching and result set caching, which can allow the client to traverse and select desired objects from the result set. A ValueListHandler object executes the search and obtains the results in a ValueList. The ValueList is normally created and manipulated by the ValueListHandler through a DataAccessObject. The ValueList is returned to the client, and the client can iterate through the list contents using a ValueListIterator.

Analysis

General Notes

In most cases, Value List Handlers do not implement common security features such as authentication and authorization, data validation and encoding, or session management. You still need to develop with standard secure coding practices such as error handling and logging.