Mitigating the WASC Web Security Threat Classification with Apache: Part 2/Page 3
[previous]
Mitigating the WASC Web Security Threat Classification with Apache: Part 2
Session Fixation
Session Fixation is an attack technique that forces a user's session ID to an explicit value. Depending on the functionality of the target web site, a number of techniques can be utilized to "fix" the session ID value. These techniques range from Cross-site Scripting exploits to peppering the web site with previously made HTTP requests. After a user's session ID has been fixed, the attacker will wait for them to login. Once the user does so, the attacker uses the predefined session ID value to assume their online identity.
Generally speaking, there are two types of session management systems for ID values. The first type is "permissive" systems that allow web browsers to specify any ID. The second type is "strict" systems that only accept server-side generated values. With permissive systems, arbitrary session IDs are maintained without contact with the web site. Strict systems require the attacker to maintain the "trap-session" with periodic web site contact, preventing inactivity timeouts.
Without active protection against Session Fixation, the attack can be mounted against any web site that uses sessions to identify authenticated users. Web sites using session IDs are normally cookie-based, but URLs and hidden form-fields are used as well.
Unfortunately, cookie-based sessions are the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of cookies.
In contrast to stealing a user's session ID after they have logged into a web site, Session Fixation provides a much wider window of opportunity. The active part of the attack takes place before the user logs in.
Session Fixation Example
The Session Fixation attack is normally a three-step process:- 1. Session set-up
- The attacker sets up a "trap-session" for the target web site and obtains that session's ID. Or, the attacker may select an arbitrary session ID used in the attack. In some cases, the established trap session value must be maintained (kept alive) with repeated web site contact.
- 2. Session fixation
- The attacker introduces the trap session value into the user's browser and fixes the user's session ID.
- 3. Session entrance
- The attacker waits until the user logs into the target web site. When the user does so, the fixed session ID value will be used and the attacker may take over.
Fixing a user's session ID value can be achieved with the techniques described in the following sections.
Issuing a New Session ID CookieValue Using a Client-Side Script
A Cross-site Scripting vulnerability present on any web site in the domain can be used to modify the current cookie value, as shown in the following code snippet:
Issuing a Cookie Using the META Tag
This method is similar to the previous one, but also effective when Cross-site Scripting countermeasures prevent the injection of HTML script tags, but not meta tags. This can be seen in the following code snippet.
Issuing a Cookie Using an HTTP Response Header
The attacker forces either the target web site, or any other site in the domain, to issue a session ID cookie. This can be achieved in the following ways:
|
Note: A long-term Session Fixation attack can be achieved by issuing a persistent cookie (e.g., expiring in 10 years), which will keep the session fixed even after the user restarts the computer, as shown here:
https://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201Jan2010%2000:00:00%20GMT";</script>.idc
Apache Countermeasures for Session Fixation Attacks
There are three different approaches to take for mitigating Session Fixation attacks:
|
Session Set-Up
In this phase, the attacker needs to obtain a valid session ID from the web application. If the application only sends this session ID information after successfully logging in, then the pool of possible attackers can be reduced to those who already have an account.
If the web application does provide a session ID prior to successful login, then it may still be possible to identify an attacker who is enumerating the session ID characteristics. In this circumstance, the attacker usually will try to gather a large number of session IDs for evaluation purposes to see if they can potentially predict a future value. During this gathering phase, their scanning applications will most likely trigger Mod_Dosevasive,thus alerting security personnel.
Session Fixation
During this phase, the attacker needs to somehow inject the desired session ID into the victim's browser. We can mitigate these issues by implementing a few Mod_Security filters, which will block these injection attacks:
Session Entrance When a client accesses the login URL, any session ID token provided by the client's browser should be ignored, as the web application should generate a new one. You can add the following Apache RequestHeader directive to remove these untrusted tokens:
The session ID that is generated by the web application should include a token that identifies the client's IP address. If the client IP address does not match what is stored in the session ID, then the client should be forced to re-authenticate.
References
|
Excerpted from Preventing Web Attacks with Apache by Ryan C. Barnett. Copyright © 2006. Used with permission of Pearson Education, Addison-Wesley Professional.
[previous]
URL:
Find a programming school near you