Session Fixation and Prediction
A session token is a random value that maps to an authenticated session on the server. Two properties are required: the token must be generated with sufficient entropy that it cannot be guessed, and the server must not accept session tokens that were not generated by the server itself. Session prediction attacks the first property. Session fixation attacks the second.
Session Prediction
If session tokens are generated using a weak source of randomness, an attacker who can observe some tokens may be able to predict others. This is not a theoretical concern for older frameworks.
PHP's session_id() before version 7.1 used a combination of current time, request data, and a linear congruential generator seeded with time. An attacker who knew the approximate time a session was created could enumerate a small space of likely session IDs and test them against the application. Apache Tomcat versions prior to 6.0.30 had documented session ID predictability issues tied to java.util.Random rather than SecureRandom.
Session tokens must be generated with a cryptographically secure pseudorandom number generator (CSPRNG). The token must have at minimum 128 bits of entropy. On Linux, /dev/urandom is appropriate. In application code: Python's secrets module, Java's SecureRandom, Node.js's crypto.randomBytes(). The format of the token (hex, base64) does not matter; the entropy does.
Session Fixation
Session fixation works when an application issues a session token before authentication and reuses the same token after the user authenticates. The attacker obtains a pre-authentication token, delivers it to the victim (through a URL parameter, a cookie set via XSS, or a subdomain that can set cookies for a parent domain), and waits for the victim to authenticate. After authentication, the server associates the known token with the victim's authenticated session. The attacker presents the same token and accesses the session.
The attack depends on the application's failure to regenerate the session token at privilege elevation. The same token spans the unauthenticated and authenticated states. Associating a new token with a new privilege level is the complete fix: when a user authenticates, the server invalidates the old session, generates a new token, and binds the authenticated session to the new token only.
Cookie Scope and Subdomain Attacks
A cookie set with Domain=example.com is sent to all subdomains of example.com, including attacker.example.com. If any subdomain is compromised or attacker-controlled (through DNS misconfiguration, expired domain, or deliberate provisioning), it can set cookies on the parent domain's scope.
This extends fixation: an attacker controlling staging.example.com sets a session cookie scoped to .example.com with a known value. The victim visits example.com, authenticates, and if the application does not regenerate the session, the attacker's pre-set cookie is now valid for an authenticated session.
Session cookies should be scoped to the specific host where authentication occurs, not to the parent domain, unless the application explicitly requires cross-subdomain session sharing.