Page 1 of 3   next page »

Imagine building a house starting with only a pile of timber and a lump of iron, or making a bowl of spaghetti from a sack of wheat and a bag of tomatoes. The importance of having the right materials makes the idea of building products from scratch seem absurd. Similarly, any software project that doesn't take advantage of the numerous frameworks available for any manner of development activity could be wasting valuable resources and ignoring established best practices.

The advantages of using frameworks are obvious to any developer who has implemented a complex, bug-ridden solution to a design problem that's already been elegantly addressed by a framework. And perhaps the most difficult design problems to get right are those concerning security. With the popularity of Web applications and services on the rise, there has been an increasing move to standardize security-critical tasks, such as authentication and session management, in the container or framework. This way, developers can focus on implementing business processes, rather than specialized tasks like cryptographic algorithms or pseudo-random number generation.

This article will focus on developing secure Web applications with the popular Java framework Struts. It will detail a set of best practices using the included security mechanisms. The first section will provide an overview of both Struts and Web application security as a context for discussion. Each subsequent section will focus on a specific security principle and discuss how Struts can be leveraged to address it.

Struts
Struts is a very popular framework for Java Web applications large and small because of the numerous advantages it offers developers. The main goal of the Struts framework is to enforce a MVC-style (Model-View-Controller) architecture, which means that there is a separation of concerns among different architectural components: the model is the representation of the logic, the view is in charge of displaying data to the user, and the controller is responsible for providing the user with a way to interact with the application and affect the model. A simple analogy for this is a video game, where you have a game console (the model), the television or monitor (the view), and a controller (quite appropriately, the controller). This architectural pattern promotes reuse and stability by reducing the effects of code changes (since the implementation of each component is agnostic to the implementation of the others and the model is isolated from the user).

Although it is approximately an implementation of the MVC pattern, Struts is more accurately based on the "Model 2" architecture specific to the Java servlet technology. Rather than having users access the JSPs directly, Struts applications have a "front controller" servlet that's the initial target of all requests and decides how to process requests and route users. Struts also has two different frameworks, the original (Struts Action Framework) and one based on JSF (Struts Shale). For the purposes of this article, we'll only consider the original framework.

Web Application Security
Web applications (such as those built on Struts) rely on users being able to access potentially sensitive information from all over the world over disparate untrusted networks. It's not exactly a surprise or a secret that many non-secure Web applications have been exploited, making front-page news and causing an enormous amount of problems for the organizations responsible. Application security attacks like SQL injection, cross-site scripting, session hijacking, and cookie poisoning are now mainstays in the toolkit of any hacker worth his salt, and it's becoming increasingly obvious that developers have to put more of an emphasis on security.

Organizations like OWASP (Open Web Application Security Project) and WASC (Web Application Security Consortium) have assembled a great deal of information on how to avoid common pitfalls and create more secure Web applications. These and other resources are invaluable for learning about Web application security, and this article complements them as a guide for best practices in Struts applications with respect to security. Here we'll focus on four specific types of security concerns and how they relate to Struts.

Struts & Input Validation
Input validation refers to the practice of verifying that input from an untrusted source is acceptable and safe to use. This has a significant security impact because malformed data submitted by a malicious user is the direct cause of numerous exploits (including SQL injection and cross-site scripting) and generally causes an application to behave unexpectedly and outside of its security design.

The Struts Validator plug-in lets you cleanly encapsulate all of your validation logic in XML configuration files instead of Java code. The Validator plug-in assists developers by standardizing common types of validations, preventing validation logic duplication, and being easier to verify and change (no recompilation is required). Two things to consider when using the Validator plug-in:

1. There's a mechanism to validate the code of the ActionForm (org.apache.struts.action.ActionForm, the Java class in the controller responsible for handling user data). However, this doesn't offer the advantages described above and won't be discussed here.
2. Any business-level validation should be performed in the model, and the controller should be limited to semantic validation (correct length, type, acceptable character set). For instance, in the Validator plug-in you might ensure a credit card number is the right format, but you'd ensure it's a valid card in the business logic.

1.  User input is encapsulated in one of the ValidatorForm classes (which extend ActionForm classes):

public class UserValidatorForm extends org.apache.struts.validator.ValidatorForm {
      public String firstName;
      public String lastName;
      public String phoneNumber;
      public String userId;
      ...
}

2.  Validation functions (several standard ones come pre-baked) are defined in validator-rules.xml. This rule calls a validation method from a custom class:

<validator name="userId"
classname="com.jdjexample.validator.UserIdValidator"
method="validateUserId"
      methodParams="java.lang.Object,
      org.apache.commons.validator.ValidatorAction,
      org.apache.commons.validator.Field,
      org.apache.struts.action.ActionErrors,
      javax.servlet.http.HttpServletRequest"
    msg="errors.userid">
...
</validator>

3.  Validation.xml maps which fields have to be validated by which rules:

<form-validation>
  <formset>
     <form name="userForm">
       <field property="firstName" depends="required">
        <arg0 key="firstName.displayName"/>
      </field>
       <field property="lastName" depends="required ">
         <arg0 key="lastName.displayName"/>
       </field>
<field property="phoneNumber" depends="required, mask">
<arg0 key="phoneNumber.mask"/>
<var>
     <var-name>mask</var-name>
     <var-value>
     ^\D?(\d{3})\D?\D?(\d{3})\D?(\d{4})$
     </var-value>
</var>
</field>
</field>
     <field property="userId" depends="required, userId">
     <arg0 key="phoneNumber.mask"/>
     </field>
    </form>
   </formset>
</form-validation>

Page 1 of 3   next page »