the-web-application-hackers-handbook

Chapter 13 n Attacking Users: Other Techniques 539
users to browse a catalog of products, place items into a shopping cart, check
out by submitting personal data and payment details, and then review all this
information on a Confirm Order page. In this situation, an attacker may fix an
anonymous session token with a victim’s browser, wait for that user to place
an order and submit sensitive information, and then access the Confirm Order
page using the token to capture the user’s details.
Some web applications and web servers accept arbitrary tokens submitted
by users, even if these were not previously issued by the server itself. When
an unrecognized token is received, the server simply creates a new session
for it and handles it exactly as if it were a new token generated by the server.
Microsoft IIS and Allaire ColdFusion servers have been vulnerable to this
weakness in the past.
When an application or server behaves in this way, attacks based on session
fixation are made considerably easier because the attacker does not need
to take any steps to ensure that the tokens fixed in target users’ browsers are
currently valid. The attacker can simply choose an arbitrary token and distribute
it as widely as possible (for example, by e-mailing a URL containing
the token to individual users, mailing lists, and so on). Then the attacker can
periodically poll a protected page within the application (such as My Details)
to detect when a victim has used the token to log in. Even if a targeted user
does not follow the URL for several months, a determined attacker may still
be able hijack her session.
Finding and Exploiting Session Fixation Vulnerabilities
If the application supports authentication, you should review how it handles session
tokens in relation to the login. The application may be vulnerable in two ways:
n The application issues an anonymous session token to each unauthenticated
user. When the user logs in, no new token is issued. Instead, her
existing session is upgraded to an authenticated session. This behavior
is common when the application uses the application server’s default
session-handling mechanism.
n The application does not issue tokens to anonymous users, and a token
is issued only following a successful login. However, if a user accesses
the login function using an authenticated token and logs in using different
credentials, no new token is issued. Instead, the user associated
with the previously authenticated session is changed to the identity of
the second user.
In both of these cases, an attacker can obtain a valid session token (either by
simply requesting the login page or by performing a login with his own credentials)
and feed this to a target user. When that user logs in using the token,
the attacker can hijack the user’s session.