the-web-application-hackers-handbook

538 Chapter 13 n Attacking Users: Other Techniques
Application
1. Attacker requests /login.php
and is issued with a session token
3. User logs in using the token
received from the attacker
4. Attacker hijacks user’s session
using the same token as the user
2. Attacker feeds the session token to the user
User
Figure 13-4: The steps involved in a session fixation attack
Attacker
The key stage in this attack is, of course, the point at which the attacker feeds
to the victim the session token he has acquired, thereby causing the victim’s
browser to use it. The ways in which this can be done depend on the mechanism
used to transmit session tokens:
n If HTTP cookies are used, the attacker can try to use one of the cookie
injection techniques, as described in the preceding section.
n If session tokens are transmitted within a URL parameter, the attacker can
simply feed the victim the same URL that the application issued to him:
https://wahh-app.com/login.php?SessId=12d1a1f856ef224ab424c2454208
n Several application servers accept use of their session tokens within the
URL, delimited by a semicolon. In some applications this is done by default,
and in others, the application tolerates explicit use in this manner even if
the servers don’t behave in this way by default:
http://wahh-app.com/store/product.do;jsessionid=739105723F7AEE6ABC2
13F812C184204.ASTPESD2
n If the application uses hidden fields in HTML forms to transmit session
tokens, the attacker may be able to use a CSRF attack to introduce his
token into the user’s browser.
Session fixation vulnerabilities can also exist in applications that do not
contain login functionality. For example, an application may allow anonymous