Top Linux Links You Must Click On


How to Create Secure Web Applications with Struts
Imagine building a house starting with only a pile of timber and a lump of iron

The Struts framework builds on these methods.

  • Programmatically:
    1.  Use Action Errors to wrap exceptions.

    try {
        login(username, password);
    } catch (BadLoginException) {
          ActionErrors errors = new ActionErrors();
          errors.add("login", new ActionError("bad. login"));
          return errors;
    }

    2.  Implement processExceptions in RequestProcessor.

    protected ActionForward processException(HttpServ-letRequest request,
         HttpServletResponse response,
         Exception exception,
         ActionForm form,
         ActionMapping mapping)
       throws IOException, ServletException {
         if (exception instanceof BadLoginException) {
    ...
    }

  • Declaratively:
    1.  Specify action and global exception forwards.

    <global-exceptions>
       <exception
         key="bad.login"
         type="com.jdjexample.BadLoginException"
         handler="com.jdjexample.BadLoginExceptionHandler"/>
    </global-exceptions>

    Error handling is a vital part of any application robustness and security, and each application must discern requirements about how to deal with errors. Often, these requirements will include logging security relevant errors to provide forensics information after attacks and comply with traceability stipulations in compliance guidelines. Struts lets errors be handled cleanly both in and outside of the code, with multiple points to implement custom code for unique requirements.

    Struts and Cross-Cutting Security Concerns
    Often, applications have security requirements that affect all resources, such as guarantees about privacy, or auditing requirements. Rather than try to apply the correct logic in each individual component, it's often helpful to have an "intercepting" class that funnels all the invocations and performs a common set of routines. This way, changes to overall functionality can be isolated to a small area. Struts has several different places where cross-cutting security concerns can be implemented, each with its own particular benefits.

    ActionServlet
    ActionServlet is the primary servlet in the Struts framework, and handles all requests to Struts Actions. In Struts 1.0, ActionServlet was the class to extend to change the handling of all requests to actions; however, much of the functionality of ActionServlet was refactored to the RequestProcessor class. This lets sub-application modules handle requests differently and promotes abstraction between the processing of raw HTTP requests and Struts-specific request processing, which should happen in RequestProcessor. Typically ActionServlet should only be extended if other extension points can't provide the functionality needed.

    RequestProcessor
    The RequestProcessor class is where most of the per-request processing takes place. There are many different methods that can be overridden here, but some have very direct security relevance:

    1. processRoles(): This method should be overridden for any action-level access control that must be programmatic (for instance, if the application doesn't use JAAS).
    2. processNoCache(): This method should be overridden to tag the response as "no-cache" to avoid security vulnerabilities associated with locally caching content.
    3. processException(): This method should do any special exception handling that can't be done declaratively.
    4. processValidate(): This method should do any special validation that can't be done declaratively.
    Obviously, more security concerns can be addressed by extending the RequestProcessor. This is where we see the Struts framework shine, since it lets us easily implement maintainable cross-cutting security mechanisms in our Web applications. However, it's important to note that any request that doesn't go through the action/controller servlet (e.g., for a static HTML page, JSP, image/multimedia file, etc.) isn't intercepted by the RequestProcessor and won't be subject to these controls (see Servlet Filter if this is a concern).

    Base Action
    By defining a base Action class that all other actions extend, security concerns can be addressed in the perform method and all other action classes would call the super. The disadvantage here is that all actions must extend this action, but this is a viable alternative to using a request processor.

    Servlet Filter
    The Filter class (javax.servlet.Filter) isn't Struts-related, but can be used to intercept and handle requests. Servlet Filters have the advantage of intercepting all (or some subset of) requests, not just those based on actions; if this functionality is necessary, then filters may be appropriate. An interesting use of Servlet Filters with respect to security is the security filter project (securityfilter.sourceforge.net) that emulates container-managed security, but alleviates problems with flexibility and portability. However, extending RequestProcessor is typically a cleaner solution because it centralizes the application logic in the Struts framework and requires less maintenance than using two separate libraries.

    Conclusion
    Application security is a problem that affects projects from the business goals down to the code implementation. Despite the increasing amount of knowledge and expertise available to the development community, many homegrown security solutions are used in place of established best practices. The Struts framework offers developers easy and effective security mechanisms that, when applied correctly, can significantly improve an application's overall security. While this article discusses some common issues, it's always important to consider unique security requirements and leverage best practices to suit the needs of the project as well as any included frameworks.

  • About Alex Smolen
    Alex Smolen is a Software Security Consultant at Foundstone, where he provides security consulting services to clients to help find, fix, and prevent security vulnerabilities in enterprise software. His duties include threat modeling, code review, penetration testing and secure software development lifecycle (S-SDLC) design and implementation. Alex’s speaking engagements include Enterprise Architect Summit 2005 where he spoke on emerging trends in enterprise security as well as Better Software Conference 2005. Alex graduated from the University of California, Berkeley, with a BS in electrical engineering and computer science.

    In order to post a comment you need to be registered and logged in.

    Register | Sign-in

    Reader Feedback: Page 1 of 1

    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.

    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.


      Subscribe to our RSS feeds now and receive the next article instantly!
    In It? Reprint It! Contact advertising(at)sys-con.com to order your reprints!
    ADS BY GOOGLE
    Subscribe to the World's Most Powerful Newsletters