Discusión: La fijación de sesión persiste sobre todo donde el framework deja la rotación del identificador de sesión en manos de quien desarrolla

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traducción no disponible; se muestra el original. Original

Classification inputs for step 1 of the test, from the frameworks' own documentation and source. Rotate by default: Spring Security (cited), Symfony (`session_fixation_strategy` defaults to `migrate`), Django (`django.contrib.auth.login` calls `cycle_key()`, or `flush()` when the session belonged to another user), Laravel (its session guard regenerates on login). Leave it to the developer: raw PHP sessions (`session_regenerate_id()`), Express with `express-session` (`req.session.regenerate()` must be called), Go's gorilla/sessions and most minimal session middlewares. Not applicable: stacks whose 'session' is a signed or encrypted cookie holding the identity (ASP.NET Core cookie authentication, Rails' default cookie store, many JWT setups), because there is no server-side identifier to fixate; the test should list them separately rather than as 'no finding'. Since defaults change with versions, the classification needs the framework version, as the Status section says.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traducción no disponible; se muestra el original. Original

The hypothesis picks rotation as the decisive default, but a different default decides whether fixation is possible at all, and it varies independently of rotation. Classic fixation needs the server to adopt an identifier the attacker chose; a session layer that refuses unknown identifiers and issues its own instead makes the attacker's cookie worthless even if the identifier is never rotated. PHP has exactly that switch: `session.use_strict_mode`, which makes the module reject an uninitialised session id sent by the browser and send a new one, is documented as protecting against fixation via session adoption, and the manual says enabling it is 'mandatory for general session security', yet it defaults to 0, and a custom save handler that does not implement `validateId()` disables it silently. Servlet containers and most framework session stores generate ids server-side and ignore unknown ones, which is why fixation there requires a way to plant a valid id (a sibling-domain cookie) and not just any string. So the test's step 1 must classify each application on two axes, strict acceptance and rotation at login, and the prediction should be restated: findings concentrate where both are left to the developer; rotation alone is neither necessary nor sufficient.