Common Web Application Vulnerabilities - Part 8
In this series of posts, my colleagues and I will dig into some specific, common web application vulnerabilities we observe regularly while performing network and application pentests. The intention of this series is to further expand upon a lot of the great information that already exists on the topic while preemptively addressing common questions we receive from our customers.
Part 8: Session Fixation
Session fixation is an attack against a web application’s session management functionality. The issue is not as common today given that many of the current web application technologies have session management functions built into the language. As a result, the underlying language will manage user sessions in a secure manner. However, the issue is still evident in many applications and therefore a relevant attack vector. Therefore, this posting will provide some background information regarding the vulnerability and an example scenario to show how an attacker would exploit the flaw.
OWASP (owasp.org) defines Session Fixation as follows:
“Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.”
Below are some of the common techniques used to exploit a session fixation vulnerability. The attacker will pass a known session token via:
- A URL parameter
- A hidden field either in a web form or HTML email
- A cookie that is passed via a client-side script, a META tag or a header response
The most trivial attack vector is utilizing a URL parameter, where an attacker sends a link via any means and includes the session token in the URL string. For example:
The web form is a little more complicated in that the attacker would have to house the web form on an external site (most likely a mirror of the victim site) or embed the code in an HTML-formatted email. Both are fairly easy to do; however, a little less conspicuous then just passing a URL string.
The passing of the session token in a cookie value is the most complex attack vector of the three, but it has the least chance of being noticed due to the cookie being programmatically passed in a very discrete manner. Below you will find examples of the three techniques described above.
Regardless of the attack vector, the attacker must first generate a valid session token that will be forwarded to the victim. We’ll utilize a sample web application that is vulnerable to session fixation.
Figure 1: Initial login screen
As you can see above, the attacker now has a valid session token to pass to a victim. If the attacker attempts to access the application using the newly acquired session token, the attacker would continue to receive the login screen.
Figure 2: Attacker using unauthenticated session token
From here, the attacker would use one of the vectors described below to exploit the vulnerability. In our examples, Chrome is the victim and Firefox is the attacker.
An attacker can pass a malicious URL to a victim in any number of ways, and it’s very easy to conceal the actual URL that will be requested should the victim follow the link. Therefore, we will assume that the attacker has sent the victim the following URL in an email:
Figure 3: Victim initial login screen
And like with the attacker, the victim receives the initial login page. At this point, the victim will log in with their credentials and successfully be authenticated.
Figure 4: Victim session after authentication
Now that the victim has authenticated, the attacker’s access to the application will also be authenticated using the original session token. If we refresh the browser, we will have a valid session.
Figure 5: Unauthorized access by the attacker
Hidden Form Field
Continuing with our example above, let’s assume that the attacker is able to persuade someone to visit a malicious site, or somehow inject a form into a page pointing to the legitimate login page. For example:
Figure 6: Malicious web page
The above login button would send the victim to the vulnerable site with the session token hardcoded in the form.
Figure 7: Victim access with known session token
This is very similar to the example above; however, the token is not displayed in the URL. But as you can see, the same session token has been presented to the victim. The use of the malicious form conceals the attack and makes it less obvious to the victim but ultimately has the same result. Once the victim successfully authenticates to the application, the attacker will have unauthorized access via the known session token.
Figure 8: Page vulnerable to XSS
Let’s assume again that an attacker successfully lures a victim to the vulnerable web page. And as part of the malicious link, the attacker utilizes the XSS vulnerability to set the session token.
Figure 9: XSS attack that sets the session cookie
Now that the session token has been set within the browser, the session token will be used when the victim accesses the login page.
Figure 10: Login form utilizing the known session token
Which as you can see, is the same session token that we’ve seen throughout. And like above, the outcome of the attack will be the same.
There are obviously multiple vulnerabilities that contributed to the examples above. And, overall, the attacks required additional steps or help from the victim in order to fully exploit the flaw. But to remediate the session fixation vulnerability, the best solution is to update the application code to create a new session variable once the user successfully authenticates against the application. As a result, the victim would use a session token known only to the victim.
Additionally, session tokens should never be passed via GET or POST requests, or accepted by the application, for multiple reasons:
- Session tokens could easily be passed by an attacker and unknowingly utilized by a victim.
- GET requests could reveal the session token in web server log files.
- Session tokens could be revealed to other sites via referrer headers.
In addition to creating new session tokens after a successful login, applications can also enhance the security of session tokens by doing the following:
- Expire session tokens after a finite time period.
- Include a log out function that programmatically expires the session token.
- Generate new session tokens after each request.
As stated above, many of the current programming languages include functionality to properly manage session tokens. The reader should review the session management functionality associated with the programming language of choice.
- Part 1.1 - XSS Overview and Reflected XSS
- Part 1.2 - Stored XSS
- Part 1.3 - DOM-Based XSS
- Part 4 - Command Injection Overview
- Part 5 - SQLi Overview and Examples
- Part 6 - Directory Traversal
- Part 7 - Cross-Site Request Forgery
- Part 9 - Padding Oracle Attacks
- Part 10 - Abusing Same-Origin Policy