Revocación de sesiones y cambios de privilegios

El cambio de permiso necesita una política

Una persona puede tener varias sesiones abiertas cuando un administrador retira su rol. El producto necesita definir cuándo deja de estar disponible la operación restringida y qué sucede con credenciales ya emitidas.

El comportamiento puede depender de la arquitectura: sesión consultada en el servidor, tokens con vencimiento, credenciales de integración o combinaciones de mecanismos. Una revisión debe identificar los accesos presentes y sus condiciones; no asumir que todos se revocan del mismo modo.

Dibujar el ciclo de cada credencial

Registrá cómo se emite, dónde se valida, cuánto dura y qué acción la invalida. Identificá si hay renovación, sesiones simultáneas y mecanismos para cerrar accesos desde otro dispositivo. Separá las credenciales personales de las utilizadas por servicios.

También conviene distinguir autenticación y autorización. Una sesión puede seguir identificando correctamente a una persona cuyos permisos cambiaron. La operación posterior necesita interpretar la política vigente del producto.

Una lista de comportamientos esperados

• Al cerrar sesión, definir qué credenciales deben dejar de ser válidas.
• Al retirar un rol, indicar desde cuándo se deniegan las operaciones que dependían de él.
• Al desactivar una cuenta, enumerar los accesos personales que deben revocarse.
• Al cambiar una contraseña o recuperar una cuenta, definir qué ocurre con las otras sesiones.
• Al renovar una credencial, comprobar las condiciones de la credencial anterior.
• Al cambiar de organización, revisar que no se conserve un contexto de permisos ajeno.

No todas estas acciones tienen la misma solución. La lista sirve para acordar resultados observables y evitar que un comportamiento quede decidido por accidente.

Ejemplo de prueba de regresión

En una aplicación ficticia, un administrador de A puede invitar usuarios. Se abre una sesión de prueba y luego se retira ese rol. El resultado esperado es que la siguiente invitación quede denegada según la política definida.

La comprobación debe incluir una operación que la persona todavía tenga permitida. También conviene revisar otra sesión abierta y la interfaz de administración. Registrar solo que desapareció un botón no acredita la decisión del servidor.

Qué conservar en la evidencia

Anotá evento, identidad de prueba, estado anterior, credenciales involucradas, versión y resultado. Evitá incluir el valor de tokens o cookies en el informe cuando una descripción o evidencia redactada permite explicar el escenario.

Si el comportamiento tiene una ventana temporal prevista, documentala y comprobá sus condiciones. Una espera observada no demuestra que exista una política acordada.

Referencias y revisión

Consultá OWASP Session Management y OWASP Authentication. Para evaluar estos recorridos en el producto, prepará el alcance de pentesting web.