Revision as of 12:05, 2 July 2009

Main

Project Roadmap

• The project’s overall goal is to...
  • Be a design-time security reference for developers implementing common patterns independent of specific platforms and frameworks. Pattern usage is ubiquitous in software development, and the best patterns transcend specific languages and/or frameworks; analyzing the most pivotal frameworks in web applications allows us to build security advice that developers will use far in the future. At the same time, analyzing common patterns helps manual penetration testers and source code reviewers understand where to look for vulnerabilities within an application.

• In the near term, we are focused on the following tactical goals...

1. Convert existing Core J2EE Patterns analysis word document into wiki format,

2. Solicit feedback and add additional advice to each pattern,

3. Determine next steps in group:

3.1. Add source code examples,

3.2. Start reviewing other patterns, such as Patterns of Enterprise Application Architecture, Enterprise Integration Patterns, or .Net Patterns.

Project Identification

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 [email protected] with comments or questions and help improve the guide for future developers.

Presentation-tier Patterns

INTERCEPTING FILTER

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.

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. 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. 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. Use to 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). 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. 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. 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.