Security is gaining more and more attention online. As PHP continues to be a key component of the web’s future, malicious attackers will begin to target weaknesses in PHP apps more frequently, and developers need to be ready.

I am very pleased to introduce Security Corner, a new monthly column that is focused completely on web app security. Each month, I will discuss an important topic in great detail that can help you improve the security of your PHP apps and defend against various types of attacks. These topics will not be vague, general overviews, so if you are looking for an introduction to web app security, you will be better served by other sources of information such as the PHP manual's chapter on security.

This month’s topic is session fixation, a method of obtaining a valid session identifier without the need for predicting or capturing one. The name for this type of attack originates from a publication by Acros Security entitled Session Fixation Vulnerability in Web-based Applications, although the method itself predates the publication. I will expand on the basic idea of session fixation and demonstrate some methods of prevention, all in a PHP-specific context.

Session Fixation

Session security is a vast and complex topic. One of the fundamental principles of web app security is to never trust data from the client. However, in order to achieve statefulness, the client must identify itself by sending a unique identifier. This fundamental conflict creates significant complexities for developers wanting to build secure, stateful applications. In fact, the session mechanism in any web app is likely to be that app’s most vulnerable feature, and session security is one of the most complex tasks on any platform.

There are numerous types of session-based attacks. Many of these fit into a category called impersonation (session hijacking), where a malicious user attempts to access another user's session by posing as that user. At the very least, these types of attacks require that the malicious user obtain a valid session identifier, because this is the minimum amount of information that must be used for identification.

There are at least three ways that a valid session identifier can be obtained by an attacker:

1. Prediction
2. Capture
3. Fixation

Prediction only involves guessing a valid session identifier. This guess can range from a wild guess to an educated one, depending upon the sophistication of the attack being used. With PHP's native session mechanism, valid session identifiers are extremely difficult to predict, so this is unlikely to be the weakest point in your implementation.

Session fixation is a method that tricks a victim into using a session identifier chosen by the attacker. If successful, it represents the simplest method with which a valid session identifier can be obtained.

A Simple Attack

In the simplest case, a session fixation attack can use a link:

1. <a href="http://host/index.php?PHPSESSID=1234">
2. Click here
3. </a>

Or, a redirect:

1. header('Location: http://host/index.php?PHPSESSID=1234');

Other methods include the Refresh header, whether passed as a proper HTTP header or by using a meta tag’s http-equiv attribute. The point is to get the user to visit a remote URL that includes a session identifier of the attacker’s choosing. This is the first step in a basic attack.

If successful, the attacker is able to bypass the necessity of capturing or predicting a valid session identifier, and it is subsequently possible to launch additional and more dangerous types of attacks. Think you're not vulnerable? Consider the code in Listing 1. Save this code as session.php somewhere where you can test it. After you ensure that you have no existing cookies from the same host (clear all cookies if you’re not certain), use a URL ending in session.php?PHPSESSID=1234 to visit the page. For example, http://host/session.php?PHPSESSID=1234. The script should output 0 on your screen upon your first visit. Reload the page a few times, and you should notice the number incrementing each time, indicating the number of previous visits.

Listing 1

1. <?php
2.  
3. session_start();
4.  
5. if (!isset($_SESSION['count'])) {
6.    $_SESSION['count'] = 0;
7. } else {
8.    $_SESSION['count']++;
9. }
10.  
11. echo $_SESSION['count'];
12.  
13. ?>

With a different browser, or even an entirely different computer, go through the exact same initial steps. Upon visiting the URL for the first time, you will notice that you do not see 0. Rather, it recalls your previous session. Thus, you have impersonated the previous user. Now, if you consider that this all began with a session identifier being passed in the URL, you should see the basic danger that session fixation presents. Unlike a typical scenario, PHP did not generate the session identifier.

There are a few shortcomings to this simple attack. The most important shortcoming is that the target application must use the session identifier passed to it, otherwise this attack will fail. If your session mechanism is nothing more than session_start(), your applications are vulnerable, as the previous demonstration illustrates. In order to prevent this specific vulnerability, you should always ensure that a new session identifier is used whenever you are starting a session for the first time. There are many ways this can be achieved, and one example is given in Listing 2 (this approach, too, has at least one weakness, so wait until you finish this article before deciding on the solution that best fits your needs).

Listing 2

1. <?php
2.  
3. session_start();
4.  
5. if (!isset($_SESSION['initiated'])) {
6.    session_regenerate_id();
7.    $_SESSION['initiated'] = TRUE;
8. }
9.  
10. ?>

If the code in Listing 2 is used to start all sessions, any existing session will always have a session variable named initiated that is already set. If this is not the case, the session is new. The call to session_regenerate_id() replaces the current session identifier with a new one, although it retains the old session information. So, if the attacker coerced a user into using an external link to your application that contains the session identifier, this approach will prevent the attacker from knowing the new session identifier, unless the session has already been initiated.

A Sophisticated Attack

A more sophisticated session fixation attack is one that first initiates a session on the target site, optionally keeps the session from timing out, and then executes the steps mentioned previously.

An alternative to the approach used in Listing 2 is to call session_regenerate_id() whenever a user successfully logs in, since this is the moment the session data becomes sensitive for most applications. For example, whenever you validate a user’s username and password, you might set a session variable that indicates success:

1. $_SESSION['logged_in'] = TRUE;

Just prior to setting such a session variable, a call to session_regenerate_id() can help to protect against a session fixation attack:

1. session_regenerate_id();
2. $_SESSION['logged_in'] = TRUE;

In fact, a good approach is to always regenerate the session identifier whenever the user’s privilege level escalates, including situations where the user must re-authenticate due to a timeout. By doing this, you can be sure that a session fixation vulnerability is not the weakest aspect of your access control mechanism.

This approach is more secure than the previous example, because it adds another significant obstacle for an attacker to overcome, and it prevents sophisticated attacks where a valid session is first created and maintained. Unfortunately, it still may have at least one weakness, although your application design should already prevent it.

An Advanced Attack

In the most advanced type of session fixation attack, the attacker first obtains a valid account on the target application — and this is typically only appealing when the attacker can do so anonymously. On some PHP applications, the login page is a separate script, such as login.php, and this script may not check the user’s state, because it seems safer to assume that the user has not been authenticated.

On the contrary, this approach can allow an attacker to create a session, log into the application with that session, optionally keep the session from timing out, and use the URL to the login page to launch the attack. If the login page accepts the new user’s login but fails to regenerate the session identifier (because the privilege level has not changed), a vulnerability exists.

This scenario may seem unlikely, but a thorough examination of your code with this situation in mind is well worth your time. There are two easy ways to prevent this particular issue:

1. Have the login page recognize the user’s state.
2. Always regenerate the session identifier on the receiving script, regardless of the user’s state.

Until Next Time…

A good generic recommendation for preventing session fixation attacks is to regenerate the session identifier anytime the user provides authentication information of any kind. Be wary of passing along such a simplistic catch-all suggestion, however, because misinterpretations are likely when someone is unfamiliar with the type of attack being prevented. There is no substitute for a good understanding of session fixation, and it is possible that the best prevention for your applications is not even mentioned in this article.

Hopefully, you can now eliminate session fixation from your list of serious security risks with which to be concerned. If you develop a particularly creative method of prevention, I would love to hear it.

Until next month, be safe.