Nave Ed

Need for a Solution Many Web applications contain sensitive data that requires some sort of password protection scheme. The application must always keep the login page intact until the user supplies a valid credential—only then he can visit his authorized area. When the authorized user logs out from the application, any new user (or a recurring visitor) should not be allowed access without providing his valid credentials. To achieve this, when a user visits the application and enters a valid username and password, a session object is created. As it turns out, HTTP basic and form-based authentication approaches do not provide a mechanism for handling logout. The solution therefore is to employ a custom security implementation, as it provides the most flexibility. A common practice in the custom authentication approach is to retrieve user credentials from a form submission and check against the backend security realms such as LDAP (lightweight directory access protocol) or RDBMS (relational database management system). If the supplied credential is valid, the login action saves some object in a Session object (say an HttpSession). This object indicates that the user has logged in to the Web application. The logout action simply involves removing the user’s details or preferences and calling the invalidate() method on the user's HttpSession object.

Example: //... session.removeAttribute("User"); session.invalidate(); //…

For both the login and logout actions to be meaningful at all, all protected JSP pages must first check the user’s identification (say the username) contained in HttpSession (or similar session object) to determine if the user is currently logged in. If HttpSession contains the identification (the username string as an example) - an indication that the user is logged in— the Web application would send to the browsers the dynamic content in the rest of the JSP page.

Notes ➢ The application behaves correctly by preventing the dynamic content of the protected JSP pages, for example the home page or other secure pages, and the logout page from being served if the user has not logged in, or after he has logged out. In other words, assuming the user has not logged in but points the browser to those JSP pages' URLs, the Web application forwards the control flow to the login page with the error message "Session has ended. Please log in.”.

➢ The application does not behave correctly if, after the user has already logged out, he clicks on the Back button to navigate back to the previous pages. The protected JSP pages reappear on the browser even after the session has ended (with the user logging out). However, continual selection of any link on these pages brings the user to the login page with the error message "Session has ended. Please log in.".

Prevent the browsers from caching The root of the problem is the Back button that exists on most modern browsers. When the Back button is clicked, the browser by default does not request a page from the Web server. Instead, the browser simply reloads the page from its cache. This problem is not limited to Java-based (JSP/servlets/Struts) Web applications; it is also common across all technologies and affects PHP-based (Hypertext Preprocessor), ASP-based, (Active Server Pages), and .Net Web applications.

After the user clicks on the Back button, no round trip back to the Web servers or the application servers should take place. The interaction occurs among the user, the browser, and the cache. The caches that sit between the application servers and the browsers can either be a good thing or a bad thing. These caches do in fact offer a few advantages, but that's mostly for static HTML pages or pages that are graphic- or image-intensive. Web applications, on the other hand are more data-oriented. As data in a Web application is likely to change frequently, it is more important to display fresh data than save some response time by going to the cache and displaying stale or out-of-date information. Fortunately, the HTTP "Expires" and "Cache-Control" headers offer the application servers a mechanism for controlling the browsers' and proxies' caches. The HTTP Expires header dictates to the proxies' caches when the page's "freshness" will expire. The HTTP CacheControl header, which is new under the HTTP 1.1 Specification, contains attributes that instruct the browsers to prevent caching on any desired page in the Web application. When the Back button encounters such a page, the browser sends the HTTP request to the application server for a new copy of that page. The descriptions for necessary Cache-Control headers' directives follow:

 

no-cache: forces caches to obtain a new copy of the page from the origin server no-store: directs caches not to store the page under any circumstance

For backward compatibility to HTTP 1.0, the Pragma:no-cache directive, which is equivalent to Cache-Control:no-cache in HTTP 1.1, can also be included in the header's response.

//... response.setHeader("Cache-Control","no-cache"); //Forces caches to obtain a new copy of the page from the origin server response.setHeader("Cache-Control","no-store"); //Directs caches not to store the page under any circumstance

response.setDateHeader("Expires", 0); //Causes the proxy cache to see the page as "stale" response.setHeader("Pragma","no-cache"); //HTTP 1.0 backward compatibility String userName = (String) session.getAttribute("User"); if (null == userName) { request.setAttribute("Error", "Session has ended. Please login."); RequestDispatcher rd = request.getRequestDispatcher("login.jsp"); rd.forward(request, response); } //...

The combination of setting the headers directives and checking for the user’s identification details in the HttpSession objects ensures that the browsers will not cache the JSP page. Also, if the user is not logged in, the JSP page's dynamic content will not be sent to the browsers, but instead the login page will.

The Refresh Issue Selecting the Refresh command from the IE and Avant browsers or resending the data from the Mozilla and FireFox browsers will result in the previous JSP page reappearing on the browsers. Obviously, this is not desirable as it defeats the purpose of the logout action. When this happens, the implication is a malicious user can still access someone else's data. This problem, however, only manifests itself when the browsers, as a result of the Back button, return to a page that was the action target of a POST request. Tracking the last logon time The above problem occurs because the browsers resubmit the data from their cache. In this case, the data consists of the username and password. Despite displaying a security warning message, as in the case of IE, the browsers in fact create an opposite effect. To fix this problem, the login page should contain—in addition to the username and password—a hidden field called lastLogon that is dynamically initialized with a long value. This long value is obtained by calling System.currentTimeMillis() and denotes the current number of milliseconds since January 1, 1970. When the form in the login page is submitted, the value from this field is first compared against the lastLogon field's value in the User database table. Only when the lastLogon value from the form is greater than the value in the database will it be considered a valid login. For valid login, the field lastLogon in the database should be updated with the form's value to update the lastLogon's time. When the browsers resubmit from the cache as in the case above, the form's lastLogon value is not greater than the database's lastLogon value, therefore the control is forwarded back to the login page with an error message stating "Session has ended. Please log in.". //... RequestDispatcher rd = request.getRequestDispatcher("home.jsp"); //Forward to homepage by default

//... if (rs.getString("password").equals(password)) { //If valid password long lastLogonDB = rs.getLong("lastLogon"); if (lastLogonForm > lastLogonDB) { session.setAttribute("User", userName); //Saves username string in the session object stmt.executeUpdate("update USER set lastLogon= " + lastLogonForm + " where userName = '" + userName + "'"); } else { request.setAttribute("Error", "Session has ended. Please login."); rd = request.getRequestDispatcher("login.jsp"); } } else { //Password does not match, i.e., invalid user password request.setAttribute("Error", "Invalid password."); rd = request.getRequestDispatcher("login.jsp"); } //... rd.forward(request, response); //...

To facilitate the above approach, you must track each user's lastLogon time. For the RDBMS security realm, this can be easily accomplished by extending the schema of the User or an equivalent table by adding a column denoting the lastLogon time. LDAP or other security realms require more thought, but the lastLogon approach can certainly work with those realms.