Fijación de sesión leída en el código

En el robo de una sesión, alguien obtiene un identificador que la aplicación ya le dio a otra persona. En la fijación ocurre al revés: alguien consigue que la víctima use un identificador que él ya conoce, y espera a que ella se autentique con él. Si la aplicación no cambia el identificador al ingresar, la sesión autenticada queda con un valor que ambos conocen. MITRE la cataloga como CWE-384.

Para que funcione hacen falta dos condiciones en la aplicación: que acepte un identificador puesto desde fuera (por ejemplo, en la URL, o uno que ella nunca generó) y que lo mantenga al pasar a autenticada. Basta con quitar cualquiera de las dos para cortarla, y lo correcto es quitar ambas.

PHP puede aceptar o rechazar un identificador que llega en la petición pero que él nunca creó. Con la opción adecuada encendida, si el valor no corresponde a una sesión existente, emite uno nuevo en lugar de adoptarlo. La documentación de PHP recomienda encenderla en todos los sitios. Otras dos opciones deciden si el identificador puede llegar por la URL además de por la cookie.

Abre php-sesion.ini en el laboratorio.

Los identificadores que genera el portal tienen una forma fija, descrita en encargo.txt. Un valor con otra forma no salió del portal. Busca en registro-portal.txt el que no encaja.

En entrar.php la sesión recibe los datos de la compradora, pero falta algo entre la verificación de la clave y la redirección. Con eso en mente, sigue el identificador del registro después del POST de las 11:41:20.

El equipo del portal quiere una sola corrección. Recuérdales que hay dos condiciones y elige el conjunto que corta ambas.