Let's begin this lesson with a quick recap on how PHP Sessions work.

When a new Session is created, the PHP engine sends a unique Session ID to the remote browser as a cookie or as a request parameter.

The Session ID is also stored in the local Session storage on the server, along with the Session data (the data inside the $_SESSION array).

When the same remote client comes back to the website, its browser sends the Session ID along with the HTTP request.

The PHP engine reads the Session ID, "recognizes" the user and restores its Session data from the server local Session storage.

Fixation attacks

The Session system has a major weakness.

The Session ID works as the remote user identifier.

Therefore, if an attacker knows the Session ID of a victim user, the attacker will be able impersonate the victim.

To obtain the Session ID of a victim user, the attacker can perform a Session Fixation attack.

This is how it works:

1. First, the attacker creates a link to the target website with an explicit Session ID parameter, like this:

2. The victim user is tricked into clicking on the link. For example, through a phishing email.
3. If the target website is not properly configured, the Session ID from the link will be set for the victim user.

In the above link, the Session ID is set as the request string PHPSESSID parameter. This is how it's set by default.

After the user clicks on the link, the PHP engine registers the Session ID from the link as the new user's ID.

The attacker, knowing the Session ID, can then go to the website using the same Session ID and impersonate the legitimate user.

The same attack can also be executed with other techniques, as long as the victim user accesses the target website with the PHPSESSID parameter set.

For example, the attacker can create a trap web page that redirects the visitor to the same link. This can be done with a simple header() statement:

In this case, the attacker just needs to make the victim user go to the trap page.

How to prevent Fixation attacks?

Let's see the reason why Fixation attacks are possible in the first place.

The root of the problem is that, by default, the PHP engine accepts explicit Session IDs set by remote users.

This is exactly what the attacker does: it sends its own Session ID to the website.

Fortunately, PHP has a specific configuration option to prevent this: use_strict_mode.

When Session Strict Mode is enabled, the user-provided ID is not accepted anymore and this type of Fixation attack stops working.

Enabling Strict Mode is also highly recommended by the PHP documentation, so there's really no reason not to enable it.

To enable it, edit your php.ini file and make sure it’s on:

Fixation attacks with Cookie-based Session IDs

As you will see in the next lessons, you can configure PHP to send the Session ID only as a cookie.

If you do so, the previous Fixation attack does not work even without strict mode enabled, because the Session ID must be sent from the victim's browser to the target website as a cookie instead of a request parameter.

But is that enough to avoid Fixation attacks altogether?

The attacker, in order to perform a Fixation attack with a cookie-based Session ID, must install a cookie with the Session ID into the victim's browser. This cookie must be relative to the target website.

However, only the target website can install a cookie for its own domain.

This makes the Fixation attack much harder for the attacker, but not impossible.

In fact, if the target website has a cross-site scripting (XSS) vulnerability, the attacker can forge the necessary JavaScript code to set the cookie...

...and inject it into the target website exploiting the XSS vulnerability.

After that, the attacker just needs to take the victim user to the hacked page (on the target website), and the cookie will be installed.

Note that any page or subdomain can set the cookie for the whole domain.

Therefore, a vulnerability on any page on a website can be exploited for this attack.

For example, the attacker can exploit an XSS vulnerability on "forum.targetwebsite.com" to install Session ID cookies for the "secure.targetwebsite.com" subdomain.

Also, if the attacker has upload access anywhere on the target website, he or she can simply create an HTML page with the above JavaScript code and upload it.

So, cookie-only Session IDs make Fixation attacks harder, but they are not enough to prevent them.

Enabling Sessions Strict Mode is always required.

Lesson takeaways

• The Session ID is how the PHP back-end recognizes returning users.
• A Fixation attack happens when an attacker makes a victim user use a specific Session ID.
• If Sessions Strict Mode is enabled, however, the server will refuse any user-provided Session ID.
• Basic Fixation attacks are prevented by enabling Strict Mode.
• Using cookie-based Session IDs makes Fixation attacks harder, but that's not enough to prevent them completely.