Ciberseguridad y seguridad de la información

Seguridad de Sesión: Cookies, Tokens y Fijación de Sesión

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la prueba de seguridad de sesión en el ámbito de Web y API PT

Respuesta rápida

La seguridad de sesión solo se prueba en un laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, los Roles, el State y el impacto, utilizando pruebas mínimas que no dañen los datos.

La prueba de seguridad Web y API debe examinar los límites de la confianza, los permisos, la entrada, el State y la lógica de negocio. Cada prueba en este artículo está diseñada para un laboratorio, CTF o un sistema para el que se ha concedido autorización explícita. El presente artículo se centra en la prueba de seguridad de sesión y está dirigido a estudiantes de Web PT. El objetivo es proporcionar una metodología que se pueda aplicar en la práctica, en una entrevista profesional y en un entorno de trabajo, sin limitarse a una definición de diccionario.

El principal desafío es que los datos casi siempre son parciales. Secure/HttpOnly/SameSite, la rotación, la expiración pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la prueba en torno a una pregunta de investigación, la evidencia requerida y un criterio claro para la finalización.

El escenario práctico en el artículo es: comparar la sesión antes y después del Login/Logout en un laboratorio. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, se debe trabajar solo con autorización explícita, un Scope definido y la capacidad de detener la prueba.

Ciclo de vida de la sesión

En la prueba de seguridad de sesión, la identidad y la autorización son dos cuestiones diferentes: quién es el cliente y qué se le permite hacer con el recurso. Se examinan los Roles, Claims, Session, la propiedad del objeto y los cambios a lo largo del ciclo de vida, y no basta con que el usuario esté 'conectado'.

Una matriz de prueba incluye un usuario anónimo, un usuario normal, el propietario de un objeto, otro usuario y un administrador. Para cada operación, se comparan la Response y el impacto en el lado del servidor. Cambiar un identificador o un Header es solo un medio de prueba; la evidencia es que el servidor aprobó o rechazó una operación en contra de la política.

Rotación y Fijación

El tema 'Rotación y Fijación' es una parte central del trabajo en la prueba de seguridad de sesión. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el propósito.

En la práctica, registre Secure/HttpOnly/SameSite, rotación, expiración, revocación, fijación, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los siguientes pasos.

Timeout y Logout

El tema 'Timeout y Logout' es una parte central del trabajo en la prueba de seguridad de sesión. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el propósito.

Tokens, Storage y Retest

Una prueba profesional de seguridad de sesión comienza con las condiciones de éxito y las condiciones de fracaso. Se definen un caso positivo, un caso negativo, un caso límite y una actividad legítima similar. De esta manera, se pueden identificar tanto falsos negativos como falsos positivos.

En un entorno autorizado, se utiliza una acción mínima que demuestre la afirmación sin causar daño. Se guardan Input, Output, tiempo y versión, y después de la corrección, se realiza un Retest en el mismo escenario y también se verifica la regresión en funciones cercanas.

Puntos de prueba únicos

En este tema, se recomienda construir de antemano un mapa de evidencia enfocado. Los principales puntos de prueba son: Secure/HttpOnly/SameSite, rotación, expiración, revocación, fijación, contexto CSRF. La lista no es una lista de verificación automática; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo, o explicar un comportamiento legítimo.

Secure/HttpOnly/SameSite: Defina cuál es el valor esperado, qué se considerará una excepción y qué fuente adicional verificará el hallazgo.
rotación: Defina cuál es el valor esperado, qué se considerará una excepción y qué fuente adicional verificará el hallazgo.
expiración: Defina cuál es el valor esperado, qué se considerará una excepción y qué fuente adicional verificará el hallazgo.
revocación: Defina cuál es el valor esperado, qué se considerará una excepción y qué fuente adicional verificará el hallazgo.
fijación: Defina cuál es el valor esperado, qué se considerará una excepción y qué fuente adicional verificará el hallazgo.
contexto CSRF: Defina cuál es el valor esperado, qué se considerará una excepción y qué fuente adicional verificará el hallazgo.

Cuando uno de los puntos no esté disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el Process identifier no es estable, se puede usar el tiempo, Host, User y Parent; si el Payload está cifrado, se utilizan Metadata, volumen, frecuencia y contexto TLS/DNS.

Proceso de trabajo recomendado

Defina el Scope y una pregunta de trabajo sobre la prueba de seguridad de sesión.
Anote las fuentes de datos y la evidencia necesaria: Secure/HttpOnly/SameSite, rotación, expiración, revocación.
Cree una línea base corta de comportamiento normal o resultado esperado.
Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
Construya una línea de tiempo o tabla comparativa y separe los hechos de la interpretación.
Realice un Pivot a una fuente adicional para confirmar o refutar la explicación inicial.
Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es la comparación de la sesión antes y después del Login/Logout en un laboratorio. El objetivo del ejercicio no es demostrar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que otro analista o evaluador pueda revisar: una captura de pantalla o Export de la evidencia, una línea de tiempo corta, una suposición inicial, evidencia de confirmación, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

Paso	Qué se realiza	Producto
Preparación	Defina el Scope, el tiempo y el objetivo. Anote qué campos o evidencias de Secure/HttpOnly/SameSite, rotación, expiración se espera que aparezcan.	Plan de prueba corto
Creación de datos	Realice una acción segura y simulada relacionada con la prueba de seguridad de sesión, sin información real o impacto en un sistema de producción.	Evento/Request/Flow controlado
Recopilación	Recopile la evidencia bruta y el contexto de una fuente adicional. Asegúrese de la zona horaria, los identificadores y la integridad.	Dos evidencias vinculadas
Análisis	Escriba lo que cada evidencia prueba, lo que no prueba y cuál es la explicación legítima posible.	Conclusión provisional
Finalización	Elija un cierre, escalada, Finding o Tuning; agregue una recomendación y Retest.	Producto documentado

Lista de verificación práctica

Verifique y documente: Role y sesión.
Verifique y documente: Endpoint y method.
Verifique y documente: Request/Response.
Verifique y documente: Object identifier.
Verifique y documente: Server-side effect.
Verifique y documente: Control esperado y remediación.
Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
Guarde los datos brutos antes de filtrar o modificar.
Escriba lo que el hallazgo prueba y lo que aún se desconoce.
Defina el propietario y la siguiente acción con una fecha.

Errores comunes

Verificar solo el Status code.
Confiar en el cambio del lado del cliente.
Utilizar un Payload peligroso.
No verificar diferentes Roles.
Ignorar la lógica de negocio.
Reportar sin Request/Response limpios.

Resumen y CTA

La seguridad de sesión: Cookies, Tokens y Fijación de Sesión es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo evidencia relevante, conserve el contexto y el tiempo, y elija una acción que se pueda justificar y volver a probar.

En el programa Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, registros y laboratorios. El paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes

¿Está permitido probar la seguridad de sesión en un sitio público?

No sin la autorización explícita del propietario del sistema. Incluso una prueba aparentemente simple puede cambiar datos, activar mecanismos de protección o considerarse acceso no autorizado.

¿Qué se hace cuando faltan algunos datos?

Se documenta lo que falta, se busca una fuente alternativa y se reduce el nivel de confianza. No se deben completar campos con suposiciones ni presentar 'Desconocido' como válido.

¿Cuánto tiempo se deben guardar las pruebas?

El tiempo depende de la política, la regulación, el costo y el tipo de evento. Es importante definir de antemano la Retención, el Legal hold y la capacidad de exportar pruebas en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Se utilizan máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En pruebas autorizadas, se definen el Scope, las Stop conditions y una copia de seguridad antes de comenzar el trabajo.