Distributed computation is about time and state. That is, in order for more than one component to communicate, state must be shared, and all that takes time.
Most programmers anthropomorphize their work. They think about one thread of control carrying out the entire program in the same way they would if they had to do the job themselves. Modern computers, however, switch between tasks very quickly, and in multi-core, multi-CPU, or distributed systems, two events may take place at exactly the same time. Defects rush to fill the gap between the programmer's model of how a program executes and what happens in reality. These defects are related to unexpected interactions between threads, processes, time, and information. These interactions happen through shared state: semaphores, variables, the file system, and, basically, anything that can store information.
Session Fixation: OAuth
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 can force a known session identifier on a user so that, after 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 1: 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 results from the 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.