Enlaces externos: » Fijación de sesiones
El administrador de sesiones de HTTP es el núcleo de la seguridad web. Se deberían adoptar todos los atenuantes para garantizar la seguridad de sesiones. Los desarrolladores deberían habilitar/emplear configuraciones relevantes de forma apropiada.
El módulo de sesión no puede garantizar que la información que se almacena en una sesión sea vista sólo por el usuario que creó la sesión. Se necesita tomar medidas adicionales para proteger activamente la confidencialidad de la sesión, dependiendo del valor asociado con ella.
Evalúe la importancia de la información que portan las sesiones y utilice protecciones adicionales; esto normalmente conlleva un precio, reduciendo la comodidad del usuario. Por ejemplo, si se quiere proteger a los usuarios de tácticas de ingeniería social simples, es necesario habilitar session.use_only_cookies. En este caso, las cookies deben estar activas incondicionalmente en el lado del usuario, o las sesiones no funcionarán.
Hay varias maneras de filtrar un ID de sesión existente a terceros. Un ID de sesión filtrado habilita al tercero a acceder a todos los recursos que están asociados con un ID específico. Primero, los URL portan ID de sesiones. Si se enlaza con un sitio externo, el URL que incluye el ID de sesión podría estar almacenado en el registro de consultas del sitio externo. Segundo, un atacante más activo podría escuchar el tráfico de red. Si no están encriptados, los ID de sesión fluirán en texto plano por la red. La solución aquí es implementar SSL en el servidor y hacerlo obligatorio para los usuarios. Se debería emplear HSTS para esto.
Desde PHP 5.5.2, está disponible session.use_strict_mode. Cuando está habilitada y el módulo genstor de almacenamiento lo admite, un ID de sesión no inicializado es rechazado, creando así un nuevo ID de sesión. Es protege contra ataques que fuerzan a los usuarios que empleen ID de sesiones conocidos. El atacante podría pegar enlaces o enviar correos que contengan ID de sesiones, p.ej., http://example.com/page.php?PHPSESSID=123456789. Si session.use_trans_sid está habilitada, las víctimas iniciarán sesión utilizando el ÏD de sesión provisto por el atacante. session.use_strict_mode mitiga este riesgo.
Incluso si session.use_strict_mode mitiga el riesgo de gestores de sesiones adoptivos, el atacante puede forzar a los usuarios a que empleen ID de sesiones inicializados creados por él mismo. Todo lo que tiene que hacer el atacante es inicializar el ID de sesión antes de atacar y mantanerlo vivo.
Se podría establecer una cookie de ID de sesión con los atributos de dominio, ruta, httponly y seguro. Los navegadores definen su propia precedencia. Al emplear la precedencia, el atacante puede establecer un ID de sesión que podría utlizarse permanentemente. El empleo de session.use_only_cookies no resolverá este problema. session.use_strict_mode mitiga este riesgo. Con session.use_strict_mode=On, los ID de sesiones no inicializados no serán aceptados. El módulo de sesiones crea un nuevo ID de sesión siempre que dicho ID no esté inicializado por él midmo. Esto podría resultar en una denegación del servicio, aunque esto es mejor que comprometer la cuenta.
session.use_strict_mode es un buen atenuante, pero no lo suficiente para sesiones autenticadas. Los desarrolladores deben emplear session_regenerate_id() para la autenticación. session_regenerate_id() debe invocarse antes de establecer la información de autentición para $_SESSION. session_regenerate_id() garantiza que las nuevas sesiones contengan información de autenticación almacenada solamente en nuevas sesiones. Es decir, los errores durante el proceso de identificación podrían guardar indicadores autenticados en sesiones antiguas.
Llamar a la función session_regenerate_id() podría resultar en una denegación del servicio personal como con use_strict_mode=On. Sin embargo, esto es mejor que comprometer la cuenta. Un ID de sesión debería ser regenerado cuando el usuario, al menos, sea autenticado. La regeneración de ID de sesiones reduce el riesgo del robo de los mismos, por lo que debería invocarse periódicamente. Los desarrolladores no deberían depender de la expiración de los ID de sesiones. Los atacantes podrían acceder a los ID de sesión de las víctimas periódicamente para evitar la expiración. Los desarrolladores deben implementar su propia utilidad de expiración para sesiones antiguas.
Observar que session_regenerate_id() no elimina sesiones
antiguas de forma predeterminada. Podrían estar disponibles las sesiones autenticadas
antiguas. Si los desarrolladores quiesieran prevenir que las sesiones autenticadas antiguas
sen utilizadas por cualquiera, debe destruir las sesiones estableciendo
delete_old_session a TRUE. Sin embargo,
la inmediata eliminación de sesiones antigas tiene efectos secundarios no deseados. Las sesiones
podrían desaparecer cuando hayan conexiones concurrentes a la aplicación
web y/o cuando la red esté inestable. En lugar de eliminar las sesiones antiguas
inmediatamente, podría establecerse un tiempo de expiración a corto plazo en
$_SESSION por uno mismo. Si el usuario accede a una sesión obsoleta
(expirada), se ha de denegar el acceso a ella.
session.use_only_cookies y el uso apropiado de session_regenerate_id() podría ocasionar una denegación del servicio personal. Cuando sea este el caso, se podría preguntar a los usuarios para que eliminen las cookies y advertirles de que podría haber problemas de seguridad. Los atacantes podrían establecer cookies maliciosas mediante una aplicación web vulnerable (es decir, inyección de JavaScript), complementos vulnerables/maliciosos de navegadores, etc.
Los desarrolladores no deben utilizar ID de sesiones de vida larga para la autoidentifiación, ya que aumenta el riego del robo de sesiones. La autoidentificación debería ser implementada por el desarrolador. Emplee la clave de hash de seguridad de una sola vez como clave de autoidentificación utilizando cookies. Emplee un hash de seguridad más fuerte que SHA-2, p.ej., SHA-256 o superior con datos aleatorios de /dev/urandom o similar. Si el usuario no se autentica, compruebe que la clave de autoidentificación de una sola vez es válida. Si la clave es válida, autentique al usuario y establezca una nueva clave de hash de seguridad de una sola vez. La clave de autoidentificación es una clave de vida larga; debería estar lo más protegida posible. Emplee los atributos ruta/httponly/seguridad de las cookies para la protección. Los desarrolladores deben implementar la característca que deshbilite la autoidentificación y elmine las claves de autoidentificación de los usuarios innecesarias.