Burp Suite: Session Timeout Vulnerabilities & Session Extension

Penetration Testing is often an exercise of observing the behavior of the target, and then finding creative ways to subvert its expectations to trigger an unusual (security-impacting) behavior. Sometimes the same techniques we use to actively identify security vulnerabilities can also be used to improve testing efficiency. 

While performing application testing, the tester has to frequently deal with application features designed to securely timeout a user’s session and force them to reauthenticate. 

In this article, we discuss the vulnerabilities related to improper session timeout and show how you can use Burp’s Intruder tool to extend sessions ad infinitum. Following these techniques will help reduce interruptions to both manual testing and long-running scans.

Identifying & Subverting Server-Side Vulnerability

To determine whether it is possible to successfully extend the session, you will need to understand the behavior of the target application and what session-related vulnerabilities it has. The following questions are helpful in making this determination:

Does the server validate when it receives expired tokens, and forcibly expire tokens after logout?

Some applications rely on browser-side controls to forcibly timeout a user’s session. Client-side JavaScript may inspect the session token and when it expires, and then forward the user to the application’s logout page. Often it’s the action of the logout page which actually invalidates the session token, while the server itself does not perform invalidation when receiving every request. 

Test Case A: After logging into the application, execute some repeatable function and forward the associated request to Burp Repeater. Submit the request in Repeater to validate that it works properly (e.g., you aren’t missing the CSRF token). Enable Proxy Interception to prevent the browser from executing the logout request, and wait for the session to expire. After it expires, use Repeater to re-execute the request, and observe whether the application call returns with data, or if you are redirected to the login page. If the request is still functional, it indicates the “No Session Timeout” vulnerability and means that you will not need to perform any session extension techniques during the test. For improved efficiency, do this over your first significant break during the test.

Test Case B: While you’re at it, you should check that the logout page actually invalidates session tokens, and doesn’t just clear the session Cookies within the browser. Follow the same procedure as Test Case A, logging into the application and forwarding the application request to Repeater. After validating that the request works in Repeater, log out of the application, and then execute the Repeater request again. If it is still successful, this indicates the “Sessions Not Terminated On Server Upon Logout” vulnerability.

Is an OAuth / Single Sign-On (SSO) provider in use?

As applications and organizations have matured to support Single Sign-On, testers must be aware of typical configurations and pitfalls related to its integration. Pay particular attention when SSO has been integrated into legacy applications. When Single Sign-On is enabled, testers may find situations where legacy expectations aren’t followed. For example, an application may handle sensitive data that necessitates allowing a 30-minute limited idle time before the session times out. When the vendor allows customers to configure their own SSO provider, they may configure it to have excessively long session durations (e.g., 24 hours) which ignores the previous control. The application may even successfully impose its own 30-minute timeout and forward the user to log in, but because their SSO token is still valid, they are immediately logged back in.

We also frequently find that target application logout behavior does not incorporate callbacks to the SSO provider to invalidate their session token. This is particularly worrying when the SSO provider session timeout far exceeds that of that application, allowing previously implemented timeout controls to be subverted. 

You can follow the same Test Cases A and B to determine if there is any risk presented due to integration mismatches with SSO. Validate that the SSO provider does not provide overly long token expiration times.

Both vendors and customers appear to appreciate the benefits of SSO:  Application vendors get to reduce their own responsibility for authentication and some session management controls, and customers do not need to manage permissions on yet another platform. In high-sensitivity environments, SSO integration should be carefully executed to make sure that session duration vulnerabilities aren’t unintentionally introduced.

Does the application use client-side controls (i.e., JavaScript) to automatically forward to a logout endpoint after token expiration?

If the application doesn’t perform any forwarding, this is “No Client-Side Session Timeout”, with its severity relative depending on the other session expiration vulnerabilities. If the server properly invalidates tokens at logout, but doesn’t validate the session token expiration for each request, you may be able to make Burp ignore the logout request and extend your session.

Test Case C: Execute Test Case A, allowing the session to expire without Interception turned on to determine if the application will automatically forward you to the logout page. You will likely inadvertently execute this test case during the first day of the test (Discovery) when you come back from lunch, so make sure to review your proxy History before you log back in and continue testing.

Here are some ideas to prevent automatic logout in this circumstance:

• Use Burp Proxy’s Find and Replace feature to modify requests to the logout endpoint. Change the URI to an invalid path (e.g., “logout” to “logoff”) to avoid your session being invalidated.
• Use Burp’s Reshaper extension to drop requests to the logout endpoint, or to blank out all Cookies sent to the endpoint before they are submitted. 
• Modify application JavaScript to jump over the logout forwarding behavior.

Is there a built-in session refresh functionality?

Applications often tell the user when they are approaching their session expiration, like in the screenshot below:

When the user clicks the OK button, a request is fired in the background to execute the “ping” command, keeping the user’s session token from timing out:

If you identify this type of design pattern in your target application, it’s not immediately indicative of a vulnerability – but you might be able to abuse these features to extend your interactive session within the browser if the server has the No Session Timeout vulnerability. As long as the Intruder attack below continues to submit requests, the session should stay fresh:

1. Send the refresh request to Burp Intruder.
2. Set an injection point within an unimportant header (e.g., at the end of the User-Agent).
3. Set payloads to “null payloads”, and to continue indefinitely.
4. Use a resource pool to limit Intruder requests to one per minute with no concurrency.
5. Execute the Intruder attack and let it run in the background.

Is there some other oddball behavior to be aware of?

Some applications do weird unexpected things, and you will need to engage your curiosity and investigate them so that you can subvert them. This application sets and checks a custom token expiration cookie using the setLastAccessTime function when the user interacts with any form on a page:

This adds additional complexity to the level of subversion that we need to perform, but with familiar solutions. Here are some ideas for subversion:

• Use Burp’s Find and Replace feature to update the PS_TOKENEXPIRE value on every request and always return a static date far in the future.
• Use Burp’s Find and Replace feature to modify the getLastAccessTime function and always return a static date far in the future.
• Use Reshaper to modify the PS_TOKENEXPIRE cookie on every request.

What’s Next?

Keep these vulnerabilities in mind during your next test to help identify and subvert them for improved efficiency while testing. The scenarios in this article describe behavior that we see frequently, but with many custom applications, there will be many weird behaviors that Burp’s default toolset cannot fully address. In novel situations, you may need to develop a new extension or use an existing extension like Reshaper to perform more surgical alterations. Consider reading our article on the Reshaper extension to help keep your scans and engagements running smoothly.