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.

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</tt> 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.

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</tt> and the values are Target</tt> objects. After a period of inactivity you want to remove the Target reference to free memory. Simply running a method like close</tt> 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</tt> class as a session bean and expose only the interfaces that clients require, hiding the complex interdependencies between BusinessObjects</tt>. Very little or no business logic should be placed within a SessionFacade</tt>.

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 </tt>objects should not encapsulate business logic. An application may contain multiple BusinessObjects</tt> (see the next pattern) that perform distinct services, but placing the business logic here introduces coupling between BusinessObjects</tt>. The Application Service pattern provides a uniform service layer for the client. An ApplicationService</tt> class acts as a central location to implement business logic that encapsulates a specific business service of the application and reduces coupling between BusinessObjects</tt>. The ApplicationService</tt> object can implement common logic acting on different BusinessObjects</tt>, implement use case-specific business logic, invoke business methods in a BusinessObject</tt>, or methods in other ApplicationServices</tt>. An <tt>ApplicationService</tt> 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. <tt>BusinessObjects </tt>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 <tt>BusinessObject</tt> 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.

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 <tt>BusinessObject </tt>and its related dependant <tt>BusinessObjects</tt> into coarse-grained entity beans. Using this pattern allows developers to leverage the EJB architecture, such as container-managed transactions, security, and persistence.

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 <tt>TransferObject</tt> 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 <tt>TransferObject</tt> 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 <tt>TransferObject</tt> 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.

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 <tt>TransferObject</tt> 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 <tt>BusinessObjects</tt>, <tt>TransferObjects</tt>, <tt>or ApplicationServices</tt> 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 <tt>Transfer Objects</tt> across different business components and return the information to the client. Think of Transfer Object Assembler as a factory to create <tt>Transfer Objects</tt>. The client invokes the <tt>TransferObjectAssembler</tt>, which retrieves and processes different <tt>TransferObjects</tt> from the business tier, constructs a composite <tt>TransferObject</tt> known as the <tt>ApplicationModel</tt>, and returns the <tt>ApplicationModel</tt> to the client. Note that the client uses the <tt>ApplicationModel</tt> for read-only purposes, and does not modify any data contained within it.

Analysis
Unauthenticated Client Calls

Allowing unauthenticated access to <tt>TransferObjectAssemblers</tt> or other middle tier components leaves applications susceptible to insider attacks. If you expose your <tt>TransferObjectAssemblers</tt> 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 <tt>DataAccessObjects</tt> 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 <tt>ValueListHandler</tt> object executes the search and obtains the results in a <tt>ValueList</tt>. The <tt>ValueList</tt> is normally created and manipulated by the <tt>ValueListHandler</tt> through a <tt>DataAccessObject</tt>. The <tt>ValueList</tt> is returned to the client, and the client can iterate through the list contents using a <tt>ValueListIterator</tt>.

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.