¿Qué almacenar en una sesión?

Question

Conozco todos los problemas con la fijación de sesión y el secuestro. Mi pregunta es realmente básica: quiero crear un sistema de autenticación con PHP. Para eso, después del inicio de sesión, simplemente almacenaba el ID de usuario en la sesión.

Pero: he visto a algunas personas hacer cosas raras como generar un GUID para cada usuario y sesión y almacenarlo en lugar de solo el ID de usuario en la sesión. ¿Por qué?

El contenido de una sesión no puede ser obtenido por un cliente, ¿o sí?

Answer 1

La respuesta corta es que $ _SESSION es seguro y no tiene que preocuparse de que su contenido se filtre a un usuario o atacante.

El contenido de la sesión no es normalmente accesible para el usuario. Debería poder almacenar la clave principal del usuario y todo irá bien. Hay casos donde se puede filtrar la sesión, en un sistema Linux normal la carpeta de sesión está en/tmp, sin embargo esto podría cambiarse en su php.ini a la raíz web (/ var/www/tmp) y luego podría estar accesible . La única otra forma es si el usuario puede obtener acceso al súper global $ _SESSION secuestrando una llamada a eval() o mediante la variable que se está imprimiendo normalmente.

Si está ejecutando en un host compartido y está utilizando una versión anterior de PHP y/o su servidor está mal configurado, otro usuario de este sistema podría leer o modificar un archivo de sesión almacenado en/tmp /. No sé de una sola aplicación que tenga en cuenta este ataque. Si esto es un problema, puede almacenar la información en una tabla session en la base de datos.

Answer 2

Estás en lo correcto. El cliente solo ve un token de id de sesión generado al azar. Hay formas en que este token puede ser mal utilizado (secuestrado, etc.), pero tener un GUID en la parte superior no agrega nada. Por el contrario, opciones como session.cookie_httponly (JavaScript no puede ver la cookie de sesión) session.cookie_secure (Las cookies solo se pueden transmitir a través de HTTPS) protegen contra ciertos escenarios de ataque.

Answer 3

A veces, para mayor seguridad, los desarrolladores pueden asignar una cadena larga a la sesión del usuario con el fin de hacer el secuestro aún más difícil. Al establecer una cookie con esta nueva cadena en el momento de la creación de la sesión, la aplicación puede verificar la cadena correcta en las solicitudes posteriores para garantizar que sea la persona que realmente inició sesión.

Simplemente agrega una cosa más a un aspirante el secuestrador tendría que adivinar. Sin embargo, puede ser una falsa sensación de seguridad, ya que protege poco la sesión si se trata de olfatear porque la nueva cookie se envía junto con la cookie de la sesión de php. Además, las identificaciones de sesión son muy difíciles de adivinar tal como están (como estoy seguro que sabes, simplemente no lo coloques en la url, sino en la cookie).

La información de la sesión se almacena en el disco duro, por lo que los clientes no pueden obtenerla sin intervención de la aplicación.

Answer 4

Nunca he visto GUIDs para sesiones, pero hay un par de métodos adicionales que he visto que agregan un poco más de seguridad.

• Almacenamiento IP del usuario - si es necesario forzar un cambio de sesión basada en localizaciones (a veces cosas geoip lo hará)
• Almacenamiento cadena de encabezado HTTP_USER_AGENT del usuario. Puede proporcionar un poco de seguridad contra el secuestro si el secuestrador usa un navegador diferente.

Hay un gran artículo en session hijacking countermeasures en Wikipedia, en realidad.

Dicho esto, me imagino que cualquiera que almacene un GUID como parte de una sesión para usar en seguridad de sesión podría no ver una solución mejor (como la regeneración de sesión). Puedo ver otros usos para guardar un GUID (quizás sea parte de un generador aleatorio para un juego), pero no para usarlo con la seguridad de la sesión.