In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache.
- Test Session Timeout (OWASP, WSTG-SESS-07)
➡ Vulnerability description for reporting available in VulnDB (GitHub)
Log and wait for timeout
First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
Use this script: session_timeout.sh
Using Burp
- Select a logged in request and send to the Intruder module.
- Under the Payloads tab:
- Select Null payloads.
- Select Continue indefinitely.
- Under the Resource pool tab:
- Select Create new resource pool.
- Delay between requests: Increase delay in increments of 300000 milliseconds (5 minutes).
- Click Start attack.
- Click on the Columns menu and add Time of day.
- Sort the results by Time of day.
- Identify the first request where the session is invalid (like 302 redirect to login page)
- To find the timeout delay, substract the Time of day values of the first invalid request with the previous request.
Look at cookie attributes
If Expire is set to “Session” for session cookie: expires when browser is closed
https://en.wikipedia.org/wiki/HTTP_cookie#Expires_and_Max-Age
As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable.
Then, if the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), testers can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., log in time, or last access time, or expiration date for a persistent cookie), then it’s possible that the client is involved in the timeout enforcing. In this case, testers could try to modify the cookie (if it’s not cryptographically protected) and see what happens to the session. For instance, testers can set the cookie expiration date far in the future and see whether the session can be prolonged.