Session Fixation: OAuth

Authenticating a user without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

Session fixation vulnerabilities occur when:
1. A web application authenticates a user without first invalidating the existing session, thereby continuing to use the session already associated with the user.
2. An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using that session identifier, giving the attacker access to the user's account through the active session.


Example: The following example shows a snippet of code from a J2EE web application where the application authenticates users with a direct post to the j_security_check, which typically does not invalidate the existing session before processing the login request.

<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password">
</form>

In order to exploit the code above, an attacker could first create a session (perhaps by logging into the application) from a public terminal, record the session identifier assigned by the application, and reset the browser to the login page. Next, a victim sits down at the same public terminal, notices the browser open to the login page of the site, and enters credentials to authenticate against the application. The code responsible for authenticating the victim continues to use the pre-existing session identifier, now the attacker simply uses the session identifier recorded earlier to access the victim's active session, providing nearly unrestricted access to the victim's account for the lifetime of the session.
Certain versions of the OAuth protocol are known to exhibit the session fixation vulnerability. The vulnerability exists in the OAuth token authorization flow which allows an attacker to get the third party application (or consumers) request token for provider authorization and trick a legitimate user to authorize the token. Once the token is authorized, it is associated with the legitimate user in the provider application. The user is then redirected back to the consumer application with an access token. Any request for data or other actions originating from the consumer application with that access token is then trusted to be coming from the user. The attacker could then use this token to masquerade as a legitimate user via the consumer application to the provider application.

This issue is a result of lack of a mechanism to ensure that the party that started the authorization flow with the consumer process is the same as the one that authorized it with the provider.

This vulnerability allows an attacker to gain unlawful access to user data stored with the provider application and perform actions against the provider application on the users behalf; effectively impersonating the user. This could lead to sensitive information disclosure, denial of service or financial loss depending on the functionality provided by the provider application.