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

When a Session is established, the PHP engine creates a unique Session ID that is sent to the remote browser as a cookie or 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.

The problem...

This system has a major weakness.

The Session ID works as the remote user identifier, but what happens if a malicious attacker somehow manages to steal the ID and impersonate the legitimate user?

A Session Fixation attack is a tricky way an attacker could achieve that result.

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 legitimate user is tricked into clicking on the link, for example with a phishing email.
3. The target website, if not properly configured, sets the Session ID used in the link as the new Session ID for the 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 user will be using the Session ID provided by attacker.

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 webpage 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 the trap page.

How to prevent this?

So, how is this kind of attack possible?

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 prohibit this: use_strict_mode.

When Session Strict Mode is enabled, no user-provided ID is 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:

Lesson Key Point

ENABLE SESSIONS STRICT MODE IN YOUR PHP CONFIGURATION TO PREVENT BASIC FIXATION ATTACKS.

Fixation attacks with Cookie-based Session IDs

As you will see in the next lessons about Session Hijacking, you can configure PHP to send the Session ID with cookies only.

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 issue a cookie for the whole domain.

Therefore, any page on a website domain can be used to install a cookie for the whole domain.

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.

Bottom line: cookie-only Session IDs makes Fixation attacks harder, but it's 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 forces the Session ID for a victim user.
• 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.