• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Insufficient Session Expiration

Page history last edited by Robert Auger 10 years, 11 months ago

Project: WASC Threat Classification

Threat Type: Weakness

Reference ID: WASC-47

 

Insufficient Session Expiration

Insufficient Session Expiration occurs when a Web application permits an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a Web site's exposure to attacks that steal or reuse user's session identifiers.

 

Since HTTP is a stateless protocol, Web sites commonly use cookies to store session IDs that uniquely identify a user from request to request. Consequently, each session ID's confidentiality must be maintained in order to prevent multiple users from accessing the same account. A stolen session ID can be used to view another user's account or perform a fraudulent transaction.

 

Session expiration is comprised of two timeout types: inactivity and absolute. An absolute timeout is defined by the total amount of time a session can be valid without re-authentication and an inactivity timeout is the amount of idle time allowed before the session is invalidated. The lack of proper session expiration may increase the likelihood of success of certain attacks. A long expiration time increases an attacker's chance of successfully guessing a valid session ID. The longer the expiration time, the more concurrent open sessions will exist at any given time. The larger the pool of sessions, the more likely it will be for an attacker to guess one at random. Although a short session inactivity timeout does not help if a token is immediately used, the short timeout helps to insure that the token is harder to capture while it is still valid.

 

A Web application should invalidate a session after a predefined idle time has passed (a timeout) and provide the user the means to invalidate their own session, i.e. logout; this helps to keep the lifespan of a session ID as short as possible and is necessary in a shared computing environment where more than one person has unrestricted physical access to a computer. The logout function should be prominently visible to the user, explicitly invalidate a user’s session and disallow reuse of the session token.

 

Example

At his town’s public library, John logs onto his bank’s Web site to transfer money from his checking account to his savings account. Once John completes his transaction he gets distracted, forgets to sign off from his bank’s Web site, and walks away from the computer. A second user, Malcolm, now uses the same computer as John. Instead of using the browser to navigate to a new site, Malcolm simply explores the browser history to return to the previous URL where John’s account information was displayed. Because John's session is still active Malcolm can now transfer money, open new accounts, order additional credit cards, or perform any other actions available to John via the bank's Web site.

 

If the banking application had enforced an inactivity timeout set for 5 minutes John’s failure to sign out would not give Malcolm the ability to use John’s session to make fraudulent transactions. Of course if Malcolm used John’s session information within that 5-minute window, John would not be protected. However, the short session expiration would drastically reduces the risk of such an occurrence.

 

References

"Dos and Don'ts of Client Authentication on the Web", Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster - MIT Laboratory for Computer Science

[1] http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

 

OWASP Guide Project: Session Management

[2] http://www.owasp.org/index.php/Session_Management

 

Insufficient Session Expiration

[3] http://cwe.mitre.org/data/definitions/613.html

 

Comments (0)

You don't have permission to comment on this page.