Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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 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.
|Forum migration complete By Athen|
|Forum migration update By Athen|