the-web-application-hackers-handbook

Chapter 21 n A Web Application Hacker’s Methodology 819
5.7.2 Check whether session expiration is implemented on the server:
n Log in to the application to obtain a valid session token.
n Wait for a period without using this token, and then submit a request
for a protected page (such as My Details) using the token.
n If the page is displayed normally, the token is still active.
n Use trial and error to determine how long any session expiration
timeout is, or whether a token can still be used days after the previous
request that used it. Burp Intruder can be configured to increment
the time interval between successive requests to automate this task.
5.7.3 Check whether a logout function exists. If it does, test whether it effectively
invalidates the user’s session on the server. After logging out,
attempt to reuse the old token, and determine whether it is still valid by
requesting a protected page using the token. If the session is still active,
users remain vulnerable to some session hijacking attacks even after
they have “logged out.” You can use Burp Repeater to keep sending a
specific request from the proxy history to see whether the application
responds differently after you log out.
5.8 Check for Session Fixation
5.8.1 If the application issues session tokens to unauthenticated users, obtain
a token and perform a login. If the application does not issue a fresh
token following a successful login, it is vulnerable to session fixation.
5.8.2 Even if the application does not issue session tokens to unauthenticated
users, obtain a token by logging in, and then return to the login page. If
the application is willing to return this page even though you are already
authenticated, submit another login as a different user using the same
token. If the application does not issue a fresh token after the second
login, it is vulnerable to session fixation.
5.8.3 Identify the format of session tokens that the application uses. Modify
your token to an invented value that is validly formed, and attempt to
log in. If the application allows you to create an authenticated session
using an invented token, it is vulnerable to session fixation.
5.8.4 If the application does not support login, but processes sensitive user
information (such as personal and payment details) and allows this to
be displayed after submission (such as on a Verify My Order page),
carry out the preceding three tests in relation to the pages displaying
sensitive data. If a token set during anonymous usage of the application
can later be used to retrieve sensitive user information, the application
is vulnerable to session fixation.