Category:OWASP Security Analysis of Core J2EE Design Patterns Project

Introduction
Most application security experts focus on a single activity for integrating design into the SDLC: threat modeling. Threat modeling is excellent at approximating an application’s attack surface but, in our experience, developers sometimes do not have the time, budget or security know-how to build an adequate threat model. Perhaps more importantly, developers cannot create a comprehensive threat model until they complete the application design.

This reference guide aims at dispensing security best practices to developers to make security decisions during design. We focus on one of the most important concepts in modern software engineering: design patterns. Ever since the publication of the seminal Design Patterns Book, developers have reused common patterns such as Singleton and Factory Method in large-scale software projects. Design patterns offer a common vocabulary to discuss application design independent of implementation details. One of the most critically acclaimed pattern collections in the Java Enterprise Edition (JEE) community is the Core J2EE Patterns book by Deepak Alur, Dan Malks and John Crupi. Developers regularly implement patterns such as “Application Controller”, “Data Access Object” or “Session Façade” in large, distributed JEE applications and in frameworks such as Spring and Apache Struts. We aim to dispense security best practices so that developers can introduce security features and avoid vulnerabilities independent of their underlying technology choices such as which Model View Controller (MVC) framework to use.

Java developers currently have access to patterns for security code (e.g. how to develop authentication, how to implement cryptography) such as the Core Security Patterns book. We hope our guide will help address the critical shortage of advice on securely coding using existing design patterns. Your feedback is critical to improving the quality and applicability of the best practices listed in the Security Analysis of Core J2EE Design Patterns. Please contact the authors at labs@securitycompass.com with comments or questions and help improve the guide for future developers.

Intercepting Filter

 * Intercepting Filter
 * Presentation Tier
 * The Intercepting Filter pattern may be used in instances where there is the need to execute logic before and after the main processing of a request (pre and postprocessing). The logic resides in Filter objects and typically consist of code that is common across multiple requests.  The Servlet 2.3 Specification provides a mechanism for building filters and chaining of Filters through configuration.  A FilterManager controls the execution of a number of loosely-coupled Filters (referred to as a FilterChain), each of which performs a specific action.  This Standard Filter Strategy can also be replaced by a Custom Filter Strategy which replaces the Servlet Specification’s object wrapping with a custom implementation.

ANALYSIS
 * Avoid Relying Only on a Blacklist Validation Filter
 * Developers often use blacklists in Filters as their only line of defense against input attacks such as Cross Site Scripting (XSS). Attackers constantly circumvent blacklists because of errors in canonicalization and character encoding . In order to sufficiently protect applications, do not rely on a blacklist validation filter as the sole means of protection; also validate input with strict whitelists on all input and/or encode data at every sink.


 * Avoid Output Encoding in Filter
 * Encoding data before forwarding requests to the Target is too early because the data is too far from the sink point and may actually end up in several sink points, each requiring a different form of encoding. For instance, suppose an application uses a client-supplied e-mail address in a Structured Query Language (SQL) query, a Lightweight Directory Access Protocol (LDAP) lookup, and within a Hyper Text Markup Language (HTML) page. SQL, LDAP, and HTML are all different sinks and each requires a unique form of encoding. It may be impossible to encode input at the Filter for all three sink types without breaking functionality. On the other hand, performing encoding after the Target returns data is too late since data will have already reached the sink by the time it reaches the Filter.


 * Avoid Overly Generous Whitelist Validation
 * While attempting to implement whitelist validation, developers often allow a large range of characters that may include potentially malicious characters. For example, some developers will allow all printable ASCII characters which contain malicious XSS and SQL injection characters such as less than signs and semi-colons. If your whitelists are not sufficiently restrictive, perform additional encoding at each data sink.


 * Avoid XML Denial of Service
 * If you use Intercepting Filter to preprocess XML messages, then remember that attackers may try many different Denial of Service (DOS) attacks on XML parsers and validators. Ensure either the web server, application server, or the first Filter on the chain performs a sanity check on the size of the XML message prior to XML parsing or validation to prevent DOS conditions.


 * Avoid Logging Arbitrary HTTP Parameters
 * A common cross-cutting application security concern is logging and monitoring of user actions. Although an Intercepting Filter is ideally situated to log incoming requests, avoid logging entire HTTP requests.  HTTP requests contain user-supplied parameters which often include confidential data such as passwords, credit card numbers and personally identifiable information (PII) such as an address.  Logging confidential data or PII may be in violation of privacy and/or security regulations.


 * Implement Input Validation
 * Use an Intercepting Filter to implement security input validation consistently across all presentation tier pages including both Servlets and JSPs. The Filter’s position between the client and the front/application controllers make it an ideal location for a blacklist against all input. Ideally, developers should always employ whitelist validation rather than blacklist validation; however, in practice developers often select blacklist validation due to the difficulty in creating whitelists. In cases where blacklist validation is used, ensure that additional encoding is performed at each data sink (e.g. HTML and JavaScript encoding).


 * Implement Page-Level Authorization
 * Use an Intercepting Filter to examine requests from the client to ensure that a user is authorized to access a particular page. Centralizing authorization checks removes the burden of including explicit page-level authorization deeper in the application. The Spring Security framework employs an Intercepting Filter for authorization.
 * Remember that page-level authorization is only one component of a complete authorization scheme. Perform authorization at the command level if you use Command objects, the parameter level such as HTTP request parameters, and at the business logic level such as Business Delegate or Session Façade. Remember to propagate user access control information such as users’ roles to other design layers like the Application Controller. The OWASP Enterprise Security Application Programming Interface (ESAPI) uses ThreadLocal  objects to maintain user authorization data throughout the life of a thread.


 * Implement Session Management
 * Session management is usually one of the first security controls that an application applies to a request. Aside from container-managed session management controls such as idle timeout and invalidation, some applications implement controls such as fixed session timeout, session rotation and session-IP correlation through proprietary code.  Use an Intercepting Filter to apply the additional session management controls before each request is processed.
 * Invalidating the current session token and assigning a new session token after authentication is a common defense against session fixation attacks. This control can also be handled in an Intercepting Filter specifically configured to intercept authentication requests. You may alternatively use a generic session management Filter that intercepts all requests, and then use conditional logic to check, specifically, for authentication requests in order to apply a defense against session fixation attacks. Be aware, however, that using a generic Filter introduces maintenance overhead when you implement new authentication paths.


 * Implement Audit Logging
 * Since Intercepting Filters are often designed to intercept all requests, they are ideally situated to perform logging of user actions for auditing purposes. Consider implementing a Filter that intercepts all requests and logs information such as:


 * Username for authenticated requests
 * Timestamp of request
 * Resource requested
 * Response type such as success, error, etc.
 * The logging filter should be configured as the first Filter in the chain in order to log all requests irrespective of any errors that may occur in Filters further down the chain. Never log confidential or PII data.

Front Controller

 * Front Controller
 * Presentation Tier
 * Processing a request typically consists of a number of request handling activities such as protocol handling, navigation and routing, core processing, and dispatch as well as view processingvii. A controller provides a place for centralizing this common logic performed for each request.  Typically implemented as a Servlet, the Front Controller can perform this common logic and further delegate the action management (servicing the request) and view management (dispatching a view for user output) activities to an Application Controller.  This pattern provides centralization of request control logic and partitioning of an application between control and processing.


 * ANALYSIS
 * Avoid Physical Resource Mapping
 * The Physical Resource Mapping strategy maps user-supplied parameters directly to physical resources such as files residing on the server. Attackers often take advantage of this strategy to gain illicit access to resources. In a directory traversal exploit, for example, clients supply the server with the physical location of a file such as “file=statement_060609.pdf”. Attackers attempt to access other files on the server by supplying malicious parameters such as “file=../../../../../etc/password”. If the application blindly accepts and opens any user-supplied filename then the attacker may have access to a whole array of sensitive files, including properties and configuration files that often contain hard-coded passwords.
 * Developers sometimes mitigate directory traversal attacks by checking for the presence of a specific prefix or suffix, such as verifying that the file parameter begins with “statement” and ends with “.pdf”. A crafty attacker can take advantage of null character injection and enter “file=statement_060609.pdf/../../../../etc/password%00.pdf”. Java will see that the resource beings with “statement” and ends with “.pdf” whereas the operating system may actually drop all remaining characters after the %00 null terminator and open the password file.
 * As a rule, avoid using the Physical Resource Mapping strategy altogether. If you must use this strategy, ensure that the application operates in a sandboxed environment with the Java Security Manager and/or employs sufficient operating system controls to protect resources from unauthorized access.


 * Avoid Invoking Commands Without Sufficient Authorization
 * In the Command and Controller strategy, users supply a Command object which the Application Controller subsequently handles by invoking an action. Developers who rely on client-side controls and page-level access control often forget to check if the user is actually allowed to invoke a given Command.
 * Attackers take advantage of this vulnerability by simply modifying a parameter. A common example is a Create Read Update Delete (CRUD) transaction, such as http://siteurl/controller?command=viewUser&userName=jsmith. An attacker can simply modify “viewUser” to “deleteUser”. Often developers assume that if clients cannot see a link to “deleteUser” on a web page then they will not be able to invoke the “deleteUser” command. We like to call this GUI-based Authorization and it is a surprisingly common vulnerability in web applications.
 * Ensure that clients are actually allowed to invoke the supplied command by performing an authorization check on the application server. Provide the Application Controller sufficient data about the current user to perform the authorization check, such as roles and username. Consider using a Context object to store user data.


 * Avoid Unhandled Mappings in the Multiplexed Resource Mapping Strategy
 * The Multiplexed Resource Mapping strategy maps sets of logical requests to physical resources. For example, all requests that end with a “.ctrl” suffix are handled by a Controller object. Often developers forget to account for non-existent mappings, such as suffixes not associated with specific handlers.
 * Create a default Controller for non-existent mappings. Ensure the Controller simply provides a generic error message; relying on application server defaults often leads to propagation of detailed error messages and sometimes even reflected XSS in the error message (e.g. “The resource alert(‘xss’) .pdf could not be found”).


 * Avoid Logging of Arbitrary HTTP Parameters
 * A common cross-cutting application security concern is logging and monitoring of user actions. Although a Front Controller is ideally situated to log incoming requests, avoid logging entire HTTP requests.  HTTP requests contain user-supplied parameters which often include confidential data such as passwords and credit card numbers and personally identifiable information (PII) such as an address.  Logging confidential data or PII may be in violation of privacy and/or security regulations.


 * Avoid Duplicating Common Logic Across Multiple Front Controllers
 * If you use multiple Front Controllers for different types of requests, be sure to use the Base Front strategy to centralize security controls common to all requests. Duplicating cross-cutting security concerns such as authentication or session management checks in multiple Front Controllers may decrease maintainability. In addition, the inconsistent implementation of security checks may result in difficult-to-find security holes for specific use cases.  If you use the BaseFront strategy to encapsulate cross-cutting security controls, then declare all security check methods as final in order to prevent method overriding and potentially skipping security checks in subclasses. The risk of overriding security checks increases with the size of the development team.


 * Implement Logical Resource Mapping
 * The Logical Resource Mapping strategy forces developers to explicitly define resources available for download and prevents directory traversal attacks.


 * Implement Session Management
 * Session management is usually one of the first security controls that an application applies to a request. Aside from container-managed session management controls such as idle timeout and invalidation, some applications implement controls such as fixed session timeout, session rotation, and session-IP correlation through proprietary code.  Use a Front Controller to apply the additional session management controls before each request is processed.
 * Invalidating the current session token and assigning a new session token after authentication is a common defense against session fixation attacks. This control can also be handled by Front Controller.


 * Implement Audit Logging
 * Since Front Controllers are often designed to intercept all requests, they are ideally situated to perform logging of user actions for auditing purposes. Consider logging request information such as:


 * Username for authenticated requests
 * Timestamp of request
 * Resource requested
 * Response type such as success, error, etc.
 * Never log confidential or PII data.

Context Object

 * In a multi-tiered applications, one tier may retrieve data from an interface using a specific protocol and then pass this data to another tier to be used for processing or as input into decision logic. In order to reduce the dependency of the inner tiers on any specific protocol, the protocol-specific details of the data can be removed and the data populated into a ContextObject which can be shared between tiers.  Examples of such data include HTTP parameters, application configuration values, or security data such as the user login information, defined by the Request Context, Configuration Context, and Security Context strategies, respectively. By removing the protocol-specific details from the input, the Context Object pattern significantly reduces the effort required to adapt code to a change in the application’s interfaces.


 * ANALYSIS
 * AVOID CONTEXT OBJECT AUTO-POPULATION STRATEGY


 * The Context Object Auto-Population strategy uses client-supplied parameters to populate the variables in a Context object. Rather than using a logical mapping to match parameters with Context variables, the Context Object Auto-Population strategy automatically matches Context variable names with parameter names. In some cases, developers maintain two types of variables within a Context object:  client-supplied and server supplied. An e-commerce application, for example, might have a ShoppingCartContext object with client-supplied product ID and quantity variables and a price variable derived from a server-side database query. If a client supplies a request such as “http://siteurl/controller?command=purchase&prodID=43quantity=2” then the Context Object Auto-Population strategy will automatically set the ShoppingCartContext.prodId=43 and ShoppingCartContext.quantity=2. What if the user appends “&price=0.01” to the original query? The strategy automatically sets the ShoppingCarContext.price=0.01 even though the price value should not be client controlled. Ryan Berg  and Dinis Cruz and of Ounce labs documented this as a vulnerability in the Spring Model View Controller (MVC) framework.
 * Avoid using the Context Object Auto-Population strategy wherever possible. If you must use this strategy, ensure that the user is actually allowed to supply the variables to the context object by performing explicit authorization checks.


 * Avoid Assuming Security Context Reflects All Security Concerns
 * The Security Context strategy should more precisely be called an Access Control Context strategy. Developers often assume that security is comprised entirely of authentication, authorization and encryption. This line of thinking often leads developers to believe that using the Secure Socket Layer (SSL) with user authentication and authorization is sufficient for creating a secure web application.

Also remember that fine-grained authorization decisions may be made further downstream in the application architecture, such as at the Business Delegate. Consider propagating roles, permissions, and other relevant authorization information via the Context object.
 * Implement Whitelist Input Validation
 * The Request Context Validation strategy uses the RequestContext object to perform validation on client-supplied values. The Core J2EE Patterns book provides examples for form and business logic level validation, such as verifying the correct number of digits in a credit card. Use the same mechanism to perform security input validation with regular expressions. Unlike Intercepting Filters, RequestContexts encapsulate enough context data to perform whitelist validation. Many developers employ this strategy in
 * Apache Struts applications by opting to use the Apache Commons Validator plugin for security input validation.

In several real-world implementations of Request Context Validation, the RequestContext only encapsulates HTTP parameters. Remember that malicious user-supplied input can come from a variety of other sources: cookies, URI paths, and other HTTP headers. If you do use the Request Context Validation strategy for security input validation then provide mechanisms for security input validation on other forms of input. For example, use an Intercepting Filter to validate cookie data.

Conceptually, Context objects form the last layer where applications can differentiate between untrusted user-supplied data and trusted system-supplied data. For instance, a shopping cart Context object might contain a user-supplied shipping address and a database-supplied product name. Generally speaking, objects logically downstream from the Context object cannot distinguish user-supplied data from system-supplied data. If you encode data at sink points and you want to minimize performance impact by encoding only user-supplied data (as opposed to system generated data), then consider adding an “isTainted” flag for each variable in the Context class. Set “isTainted” to true if the variable is user supplied or derived from another user supplied value. Set “isTainted” to false if the variable is computer generated and can be trusted. Store the instance variable and “isTainted” booleans as key/value pairs in a collection with efficient lookups (such as a WeakHashMap). Downstream in the application, simply check if a variable is tainted (originates from user-supplied input) prior to deciding to encode it at sink points. For instance, you might HTML, JavaScript, or Cascading Stylesheet (CSS) encode all tainted data that you print to stream in a Servlet while leaving untainted data as is.
 * Implement Flagging Tainted Variables