GESTIÓN DE SESIONES WEB

Aprovechando los patrones de generación de identificadores de sesión que pueda utilizar el servidor se reduce el espacio de búsqueda, y se prueba todas las posibilidades posibles mediante fuerza bruta.

Si una página web presenta una vulnerabilidad XSS un atacante puede aprovecharla para ejecutar código que capture el contenido de la cookie y se lo envíe. 

Este tipo de ataque sigue un camino distinto del resto, en vez de capturar un identificador de sesión valido, genera un identificador genuino (que no está asociado a ningún usuario por el momento) en el portal web afectado para, a continuación, tratar de que la víctima se autentique en el portal con él. De este modo, el atacante obtiene un identificador de un usuario autenticado que puede utilizar para realizar acciones en el portal afectado en nombre de la víctima.

Si se puede interceptar el tráfico web entre la víctima y el portal web, ahora más que nunca por el auge de las comunicaciones inalámbricas, también se puede capturar el identificador de sesión.(Tan fácil como abrir el Wireshark y filtrar)

Lo más simple del mundo, si el usuario ha olvidado cerrar la sesión o hemos programado mal el tiempo de validez de las cookies, simplemente podemos acceder como otro usuario.

Cada lenguaje de programación tiene sus propias herramientas para controlar las sesiones de los usuarios. Aquí vemos las de los 3 más empleados en los entornos web.

ASP.net funciona muy similar a php, con un objeto session que controla la sesión en el framework.Recomendaciones:Aleatorizar el id de sesión a almacenar y no reutilizarlos.Protección ante ataques XSS.Evitar "fijar" la sesión (actualizando o modificando el id asignado en momentos claves).Ajustar un tiempo para cerrar la sesión.Ajustar el tiempo de vida de las cookies.Utilizar HTTPs para poder habilitar cookies "seguras"

Java funciona de forma parecida pero distinta a los otros ejemplos. La información de la sessión se almacena en la memoria del servidor, pero tambien se puede (si quisieramos) usar cookies.Recomendaciones (para las cookies):Aleatorizar el id de sesión a almacenar y no reutilizarlos.Protección ante ataques XSS.Evitar "fijar" la sesión (actualizando o modificando el id asignado en momentos claves).Ajustar un tiempo para cerrar la sesión.Ajustar el tiempo de vida de las cookies.Utilizar HTTPs para poder habilitar cookies "seguras"

php guarda la sesión http en un archivo, se puede acceder mediante $_Session.Recomendaciones:Esto se utiliza conjuntamente con cookies, de la que guarda un identificador de la sesión para luego buscarlo.Borra los contenidos del archivo si no son modificados en el tiempo.Aleatorizar el id de sesión a almacenar y no reutilizarlos.Protección ante ataques XSS.Evitar "fijar" la sesión (actualizando o modificando el id asignado en momentos claves).Ajustar un tiempo para cerrar la sesión.Ajustar el tiempo de vida de las cookies.

Este informe del INCIBE, se basa en la protección de las cookies.Aunque las cookies son el recurso más utilizado para las sesiones, he querido recordar que existe otra opción e indicar sus pros y contras.

Almacenan los datos que queramosPersisten en el tiempo.Hay que generarlas manualmente.Se almacenan en el cliente.

Se generan automáticamente al establecerse la conexión con el servidor, mediante el protocolo HTTP.Pueden almacenar los mismos datos que las cookies.Consume recursos en el servidorSon "más difíciles" de codificar.