| QUESTION & ANSWER |
Adjusting a Web application's ability to cache in, log out |
 |
By Editorial Staff
17 Jan 2008 | SearchFinancialSecurity.com |
|
|
Expert Michael Cobb explains why it's easy to control an application's log-out settings -- and more difficult to manipulate client-side caching.What are some Web application security guidelines for account log-out settings and caching?
Cobb: Web applications have to establish sessions to keep track of a user's requests and account logout is a critical aspect of managing active sessions. Your application should have a method, such as a logout button or link, located on every page, which allows the user to log out. Also, users who have not logged in for a while should be locked out until they have reregistered.
You should base your timeout settings on how users are likely to interact with Web applications, as well as how sensitive the applications' data is. For example, some banking sites time-out after ten minutes due in part to the sensitive data accessed by its users. In addition, because "Remember Me" options can negate the timeout settings, you should ban automatic logons or keep-alive features.
Unfortunately, you'll have limited control over client-side caching of your application's content. If you don't want browsers to cache your content, set the cache control directives in the server response headers to influence how client-side caching is handled. If you don't want browsers to cache your pages, set the cache-control response header to no-store. This will instruct the browser cache not to store the response or any request for it. Unfortunately, no-cache and no-store are HTTP 1.1 headers and therefore are not supported by HTTP 1.0 caches. Additionally, non-HTML content, such as PDFs and Excel spreadsheets, is often cached even when the above tags are set. Another concern is that some browsers have the ability to store user-supplied form data, often insecurely. If any of your Web forms collect sensitive data, add the attribute AUTOCOMPLETE=FALSE, to warn the browser not to store the data. I say warn, because this attribute is not part of the HTML specification. If the user is on a shared PC and you consider your application high-risk, ask him or her to clear the browser's cache and history.
It is also critical that you clear the server-side session state, destroy the session on the server and overwrite any session cookies on the browser when the user logs out or the session expires, because a browser only destroys session cookies when its thread actually terminates it. This ensures that session replay attacks cannot occur after idle timeout or user log off. Also, session IDs in the URL should not be included because they can be seen by shoulder surfers, cached by the browser and stored in the referrer logs of other sites. Ideally, a user's entire session, including session identifiers, should be SSL-protected to prevent session ID exposure through network interception. Session IDs should be long, complicated, random numbers and should be expired and regenerated prior to any significant transaction, or after a certain number of requests or period of time, especially when switching to SSL. This will reduce the risk from session-hijacking and brute-force attacks. Finally, be sure to document the goals of managing application sessions and the mechanisms implemented to achieve them in your security policy.
|
|
|
|
