What is your opinion on guidelines for Web application development in terms of time-out settings, caching and other...
best practices in account log out from a security perspective?
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 this 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 log ons 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.
Dig Deeper on Web application and API security best practices
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading