Maintaining the confidentiality and integrity of information in transit is a primary function of the SSL/TLS protocol. Vulnerabilities in the protocol implementation could however severely compromise these guarantees. Failure to establish a cryptographic binding of a handshake to the enclosing session causes the SSL/TLS renegotiation protocol to fall victim to man-in-the-middle attacks that could allow an attacker to inject plaintext into the protocol stream. Renegotiation was developed to support long running sessions where encryption keys will need to be changed to ensure cryptographic security. However, the real problem manifests within the application using SSLv3/TLS. Since HTTP requests cannot be processed until they are complete, web servers cache the request until it is finished. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted. This indeterminate buffer state is the manifestation of the problem. Unfortunately, servers vulnerable to this attack are SSLv3/TLS enabled web servers that do NOT flush the request buffers prior to the renegotiation of SSL Keys. Thus an attacker can leverage this oversight to inject data into the beginning of the conversation between unsuspecting clients and the web server.

A server configured to use the vulnerable protocol implementation will expose the hosted applications to malicious data injection exploits. An application that lacks appropriate input filters to reject incoming malicious requests could allow an attacker to steal the authentication credentials of users which can lead to further compromises using the stolen privileges.

OAuth2 protocol implementations that do not use the state parameter value with sufficient entropy are susceptible to a CSRF vulnerability that might give an attacker the ability to login to the victim's current application account using a third-party account without any restrictions.
In authorization code type and implicit grant type, the OAuth2 protocol is vulnerable to a CSRF attack if the state parameter value is predictable. An attacker can perform a normal OAuth2 process and get the redirection URL that contains the authorization code for the third-party. The attacker can bind their own account to the victim's account for the vulnerable application by enticing a victim to access this URL. If the state parameter is set in the redirection URL but without sufficient entropy, then an attacker can predict the user's state parameter and forge a reliable redirection URL to persuade the victim to access and then implement a CSRF attack.

The application transmits a password via unencrypted channels and may pose a significant security risk to the users of that application. Some examples are Basic authentication which sends authentication credentials in plain text over HTTP or form-based authentication credentials sent via HTTP are vulnerable to interception via man-in-the-middle (MiTM) attacks.

Authentication is an important aspect of security. The reliability of the authentication process depends on the security and strength of the login credentials. Password policies that ensure users create strong passwords are therefore crucial to deploying secure websites. Password strength is a measure of the effectiveness it provides in resisting guessing and brute force attacks. Some of the parameters that help define the password strength include password characteristics such as password length, complexity and randomness.

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.

Session Identifiers are typically generated using a pseudorandom number generator (PRNG). If a PRNG doesn't yield enough entropy for a strong session identifier, it's susceptible to statistical analysis. If an attacker can predict a valid session identifier, the corresponding session can be immediately hijacked.
If an attacker can obtain a valid session ID, the corresponding user data can be accessed. If the victim user has administrative privileges the attacker can gain full control over the operation of the target application.
An attacker can exploit a weak session identifier by:
1. Collecting a sample set of valid session identifiers through multiple sign ins
2. Identifying static and dynamic data trunks in the session identifiers based on the structure observed in the samples
3. Generating new valid session identifiers by sequentially increasing or decreasing dynamic data
4. Stealing information or accessing resources restricted to the users to whom the generated session identifiers are assigned
The 64-bit entropy is the known threshold that makes session ID guessing attacks impractical. For example, if a large website issues a 64-bit session ID with 32-bit entropy, it allows an attacker to attempt 1,000 guesses per second. If the web site has a user base of 10,000, an attacker will require need approximately 4 minutes to deduce a valid session identifier.

The web application should specify a session identifier length of at least 128 bits long. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session allowing him to launch impersonation attacks against application.