Home arrow Java arrow Page 7 - Securing Struts Applications

Securing Struts Applications

Web applications often require that certain parts of the system be secured. Some security requirements can be satisfied with standard security mechanisms, while others call for a customized approach. Sometimes, as a developer, you may need to use a combination of these two techniques. This article helps you examine the issues and techniques. It is excerpted from chapter 19 of the book The Complete Reference: Struts, written by James Holmes (McGraw-Hill/Osborne, 2004; ISBN: 0072231319 ).

Author Info:
By: McGraw-Hill/Osborne
Rating: 5 stars5 stars5 stars5 stars5 stars / 111
September 15, 2005
  1. · Securing Struts Applications
  2. · Using Container-Managed Security
  3. · BASIC Login
  4. · FORM-Based Login
  5. · Application-Managed Security
  6. · Page/Action-Level Security Checks
  7. · Using Cookies
  8. · SSLEXT to the Rescue

print this article

Securing Struts Applications - Using Cookies
(Page 7 of 8 )

A cookie consists of name-value data that can be sent to a client’s browser and then read back again at a later time. Persistent cookies are stored by the client’s browser. Cookies can be read only by the same server or domain that originated them. Also, a cookie can have an expiration period. Cookies are supported by most major browsers. However, cookies are often considered a privacy risk and can be disabled by the client. A good approach is to design your Web application to use cookies to improve the user experience, but not to require or force users to allow cookies.

For application-managed security, you can use cookies to allow users automatic logins. Specifically, you can create a persistent cookie that contains the user’s username and password. Then, when a user accesses the application, you can check for those cookie values. If present, the values can be used to log the user in without requiring them to fill out a login form. Using a servlet filter, or some JavaScript, you could log in a user automatically. Alternatively, you may want to just prepopulate the login form with the values from the cookie.

To illustrate the use of cookies, Mini HR will be changed to use them as follows:

  1. Once a user logs in, Mini HR creates persistent cookies containing the username and password.
  2. Mini HR uses the cookie support of the Struts tags to set the initial values for the login form.


For the login action, this means adding the following lines after the authentication check has been performed:

Cookie usernameCookie = new Cookie("MiniHRUsername", username);
usernameCookie.setMaxAge(60 * 60 * 24 * 30); // 30 day expiration
Cookie passwordCookie = new Cookie("MiniHRPassword", password);
passwordCookie.setMaxAge(60 * 60 * 24 * 30); // 30 day expiration

This code creates cookies for holding the username and password. Each cookie has an expiration of 30 days. Each cookie is then added to the response.

Next, use the Struts bean tags to retrieve the cookie values and write the values to the login form:

<logic:notPresent name="user" scope="session"> 
<bean:cookie id="uname" name="MiniHRUsername" value=""/>
<bean:cookie id="pword" name="MiniHRPassword" value=""/>
<hr width="100%" noshade="true">
<html:form action="/login">
Username: <html:text property="username"
    Password: <html:password property="password"
    <html:submit value="Login"/>

The cookie tags retrieve the cookie values from the request and store them in page scope variables. These variables are then used as the initial values for the login form fields. However, this example is too simplistic for production use. Generally, using cookies without input from the user is considered overly presumptuous. A good Web application lets the user specify whether they want their user data stored as a cookie. It is also reasonable to let the user specify the length of time before the cookie expires. This type of information is easily gathered and stored by an application. Typically, this information is collected at registration time and stored as part of the user’s profile.

In addition, the data sent in the cookies should be secured or encrypted. A simple encryption scheme, such as MD5 or a variant of the Secure Hash Algorithm (SHA), can be used to encrypt the cookie value when it is created. Since the server creates the cookie and is the only party to legitimately use the data, it can encrypt and decrypt the data using the algorithm of its own choosing. Alternatively, cookies can be configured to only be transmitted over HTTPS—thereby providing encryption/decryption at the transport level.

Integrating Struts with SSL

Web applications often need to allow certain operations to be performed under secure processing—that is, using HTTPS. Users have come to expect sensitive data such as their usernames, passwords, and credit card numbers to be transmitted over a secure channel. As was noted earlier, the use of HTTPS for specific URLs can be specified using a user data constraint within a security constraint in the web.xml file. This declarative mechanism can be used to restrict URLs to SSL (by specifying a transport guarantee of INTEGRAL or CONFIDENTIAL). However, this approach does not address all the issues when using SSL. As a container-managed service, the implementation and behavior with SSL can vary by container. If the service is not used carefully and with a full understanding of its nuances, it is easy to code an application that will only run in a specific container—even when using services that are defined via an industry-accepted specification.

Therefore, HTTPS typically is used only when passing sensitive data, and otherwise HTTP is used. This requires redirecting from nonsecure pages to secure pages and then back again. Performing this redirection requires changing the protocol scheme on a URL from http to https on each redirection. The biggest problem with needing to do this protocol switching is that absolute URLs must be hard-coded into JSP pages and Action classes. This quickly leads to deployment and maintenance problems that arise when server names are different between development, integration test, and production servers. Some techniques for overcoming this problem are described shortly.

More pragmatically, programming an application to use HTTPS has other, more mundane but nevertheless equally frustrating issues. A common one is that the https protocol of the URL must often be hard-coded into a page. In fact, generally if you create HTML links that reference HTTPS, you must specify a fully qualified absolute URL. This makes it difficult to develop an application that is easy to migrate between deployment servers. Also, because switching the protocol requires an HTTP redirect, request attributes for the current request cannot be propagated to the secure URL. Thankfully, there is an open-source solution for handling these types of problems.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials