Insufficient Session Expiration: Testing

Insufficient Session Timeout is a security flaw that can mean a few different things. One common finding for this is that the session timeout is set too long. For example, the session is valid after an hour of being idle. Another common finding is when the session is not properly terminated after the user uses the logout/sign out feature. In this post we will cover these two test cases and how to test for them.

A.K.A

• Insufficient Logout
• Insecure Logout
• Insufficient Session Timeout

Testing Session Timeout

The first step when testing the timeout of a session is to understand what an acceptable timeout should be. This differs depending on your organization and the type of application you are testing. Many financial applications have much more strict timeouts around 15 minutes or less. On the other hand, some social media sites may have sessions that are good for months or even longer. Those longer ones are outside the scope of this post.

• Log into the application.
• Don’t use the application (just leave it open).
• Once the expected timeout has occurred, try accessing the site to ensure your session has expired and you should be redirected to the login screen.
• If the application didn’t end the session as expected, wait even longer (try doubling the time) and test again. Keep doing this until you determine how long the session lasts or until the valid time crosses a specific threshold.

You may want to try this in a different browser than your normal browser so you can continue other testing in your normal browser without effecting the timeout.

Testing Insufficient Logout

The goal of this test is to verify that the sign/log off function is invalidating the entire session. Below are the steps to validate this.

• Start a proxy (such as Burp Suite) and configure your browser to send all traffic through it.
• Log into the application and identify the cookies used to manage the session. These could be session identifiers like the ASP.Net session id, PHP Session id, or JSessionId to name a few, or authentication cookies like the ASP.Net forms authentication cookie.
• Copy the respected session related cookies, these will be used later.
• In Burp, you could send an authenticated request to Repeater to be replayed later (don’t use the login request).
• In the browser, execute the logout feature.
• In the browser, verify that a request to the application redirects you to the login form.
• Send a new request with the captured session cookies to see if you are granted access to the application or if you are redirected to the login screen.
• In Burp, just replay the stored request in Repeater.
• If you are granted access to the resource, the logout was not successful.
• If you are redirected to the login screen, the logout was successful.

Reporting

When reporting the finding make sure that as much detail as possible is included. Accurately classifying the finding and providing steps to reproduce the issue help the application team understand the flaw and assess the risk. It also helps the developer really understand the flaw and any other tester retest it when ready. Include the cookies that were not being properly cleared if possible. With analytics in all applications, identifying non-session related cookies may just slow things down. Don’t be afraid to try the steps above with different cookie combinations. Remove one cookie at a time to see what happens.