Session Fixation
Session fixation vulnerabilities typically arise when an application creates an anonymous session for each user when they first access the application. If the application contains a login function, this anonymous session will be created prior to login and then upgraded to an authenticated one after they have logged in. The same token that initially confers no special access later allows privileged access within the security context of the authenticated user.
In a standard session hijacking attack, the attacker must use some means to capture the session token of an application user. In a session fixation attack, on the other hand, the attacker first obtains an anonymous token directly from the application, and uses some means to fix this token within a victim’s browser. After the user has logged in, the attacker can use the token to hijack the user’s session.
The steps involved in a successful session fixation attack are illustrated in Figure -1.
Figure -1: The steps involved in a session fixation attack
The key stage in this attack is of course the point at which the attacker feeds to the victim the session token that he has acquired, thereby causing the victim’s browser to use it. There are various techniques that the attacker may use to fix a specific token for a target user, depending upon the mechanism used by the application for transmitting session tokens. The two most common techniques are:
■ Where an application transmits session tokens within a URL parameter, the attacker can simply feed the victim the same URL that was issued to him by the application, for example:
https://wahh-app.com/login.php?SessId=12d1a1f856ef224ab424c2454208
■ Where an application transmits session tokens using HTTP cookies or hidden fields in HTML forms, the attacker can exploit a known XSS or header injection vulnerability to set these values within the user’s browser. In the case of cookies, this attack will succeed in hijacking the user’s session even against applications that issue HttpOnly cookies, and so where cookies cannot be straightforwardly captured via an XSS attack.
Finding and Exploiting Session Fixation Vulnerabilities
If the application supports authentication, you should review how it handles session tokens in relation to the login. There are two ways in which the application may be vulnerable:
■ The application issues an anonymous session token to each unauthenticated user. When the user logs in, no new token is issued — rather, their existing session is upgraded to an authenticated session. This behavior is common when the application uses the application server’s default session-handling mechanism.
■ 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 — rather, 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.
If the application does not support authentication, but does allow users to submit and then review sensitive information, you should verify whether the same session token is used before and after the initial submission of user-specific information. If so, then an attacker can obtain a token and feed this to a target user. When the user submits sensitive details, the attacker can use the token to view the user’s information.
Preventing Session Fixation Vulnerabilities
At any point at which a user interacting with the application transitions from being anonymous to being identified, the application should issue a fresh session token. This applies both to a successful login and to cases where an anonymous user first submits personal or other sensitive information.
As a defense-in-depth measure to further protect against session fixation attacks, many security-critical applications employ per-page tokens to supplement the main session token. This technique can frustrate most kinds of session hijacking attacks.
The application should not accept arbitrary session tokens that it does not recognize as having issued itself. The token should be immediately canceled within the browser, and the user should be returned to the start page of the application.
NEXT is..Attacking ActiveX Controls………………………,,,,,,,,,,,,,,,,,,,,,,,
