Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Revisiting the logout problem

Recipes for JSF and Stripes

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

In my previous article, "Solving the Logout Problem Properly and Elegantly" (JavaWorld, September 2004), I addressed the logout functionality in a Web application, specifically the problem created by a browser's Back button. The solution I proposed indeed prevents users from accessing any restricted page via the Back button once they complete the logout process. However, if logged out users continue clicking the Back button, they will eventually come back to the resource that was the action of the login-form POST request. And at this point, the browser begins displaying confusing warning messages.

The confusing warning messages appear in IE browsers as follows:

Warning: Page has Expired. The page you requested was created using information you submitted in a form. This page is no longer available. As a security precaution, Internet Explorer does not automatically resubmit your information for you

To resubmit your information and view this Webpage, click the Refresh button.

And in Firefox browsers:

The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action from the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel.

Now, without resupplying the user ID and password, by just simply clicking on the OK button, users (or hackers) can access restricted resources again, which defeats the purpose of the logout process. In my previous article, we tracked the last login time to address this security hole. This solution gets the job done, but is not ultimately perfect.

This article revisits the problems created by the browser's Back button and eliminates the remaining flaw by preventing such warning messages from ever appearing. The previous solution targeted JSP (JavaServer Pages) and Struts. In this article, I present a solution for both JavaServer Faces and Stripes, two popular Java-based Web frameworks. By the end of this article, readers will have two recipe-style JSF and Stripes solutions that many Web applications, such as Microsoft Office Project Web Access, still lack.

Note: I assume readers are already familiar with both JSF and Stripes, as this article is not a beginner's tutorial on how to use those frameworks.

The problem with JSP/servlet forward

The reason why the browser throws the confusing warning messages and allows a security hole must first be explained. The controller that is the action of a login-form POST "naively" dispatches a forward to a second JSP page upon authenticating the credential. Figure 1 depicts the control flow.

Figure 1. Forward dispatch after login form POS

The problem stems from the fact that a JSP/servlet forward dispatch is entirely internal to the container, and the browser is only aware of the original action resource, namely loginAction.jsp. After the login form submission (with a valid user ID/password) and the forward dispatch, the dynamic HTML content of securePage.jsp is served to the browser. With each subsequent browser's reload/refresh, the browser reloads loginAction.jsp, not securePage.jsp, since it only knows the former and the latter is completely transparent to it. Since loginAction.jsp is the action of a POST request that contains input data, the browser displays the warning messages for confirmation purposes. The browsers behave similarly when reloading the resource loginAction.jsp after users click the Back button. With the browsers remembering the POST input data, and with users (or malicious hackers) simply clicking the warning message's OK button, users (or hackers) can access restricted resources again, which defeats the purpose of the logout process. I came up with a solution that tracks last login time, which I described in my previous article, but it needs improvement.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comments (1)
Login
Forgot your account info?

RejectBy Anonymous on October 21, 2008, 4:27 pmI emphatically reject this solution. The reason JSF was developed was to move logic to "backing beans" and avoid any logic in the jsp files. If you can't figure...

Reply | Read entire comment

View all comments

Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources