El escenario es el siguiente:
- Una aplicación tiene una interfaz web a través de la cual se pueden configurar los datos. Los datos a considerar para esta pregunta son los usuarios que tienen una relación de muchos a muchos con los grupos.
- Cada grupo tiene uno o más usuarios administradores.
- Se pueden iniciar sesión en varios usuarios de administrador de diferentes grupos a la vez.
Considere el siguiente caso de uso:
- Un usuario administrador inicia sesión en la interfaz web y elige ver una lista de usuarios en su grupo.
- El usuario administrador selecciona un usuario para editar (por ejemplo, cambiar los privilegios).
- El usuario administrador se redirige a una página de edición para un solo usuario con el ID de usuario normal en un campo oculto en la página de edición.
- El usuario administrador ingresa un nuevo privilegio en el formulario y lo envía.
- La aplicación web actualiza los privilegios normales del usuario en la base de datos.
- Este aspecto de la aplicación web no requiere optimizaciones de rendimiento, las operaciones del orden de unos pocos segundos son aceptables.
Es ingenuo creer que la ID del usuario normal no se puede editar en el lado del cliente, lo que permite al usuario administrador rojo del grupo rojo cambiar los privilegios de un usuario normal del grupo azul (del cual el usuario administrador rojo no es un miembro).
¿Qué se puede hacer en el lado del servidor para proteger la integridad de la ID del usuario normal que se está editando?
A los efectos de esta pregunta, suponga que el usuario administrador de Red se ha autenticado correctamente y se le permite ver la página de edición de un usuario normal del grupo rojo. Me preocupa aquí que el usuario administrador de Red cambie maliciosamente la identificación de usuario oculta de un usuario normal del grupo rojo para cambiar las propiedades de los usuarios de otros grupos.
Específicamente, este sistema se desarrolla utilizando Java EE ejecutándose en un servidor Glassfish.
He considerado las siguientes soluciones:
- Incruste una suma de comprobación criptográfica que incorpore la ID de usuario como un campo oculto en el formulario de edición. Un hash MD5 o similar sería inapropiado ya que el usuario administrador de Red solo tendría que calcular el nuevo hash. El hash debería derivarse de algún secreto del lado del servidor. Obviamente, el secreto debería ser impredecible y protegido.
- Actualmente, el sistema utiliza un bean de sesión sin estado para llevar el ID del usuario normal que se va a editar de la lista de Usuarios del Grupo Rojo a la página de edición del Usuario. Podría cambiar el bean de sesión para que sea un bean con estado. Mantendría la ID de usuario que se editará en el servidor, pero estoy considerando otras alternativas.
¿Qué otras opciones debo considerar para combatir esta amenaza en particular? Los temas como la autenticación de usuario y la transmisión segura están fuera del alcance de esta pregunta.