¿Cuáles son las implicaciones de seguridad de tener una cuenta de usuario ficticia que represente a usuarios no autenticados?

3

En mi aplicación web, los usuarios se asignan a grupos y a los grupos se les otorgan permisos sobre los objetos. La aplicación expone algunos objetos a usuarios públicos no autenticados (es decir, personas que visitan el sitio web de manera informal).

He pensado en tener un atributo de objeto "visible para el público" que otorgue acceso a los usuarios no autenticados.

También he pensado en crear un grupo llamado Público y otorgarle permisos a ese grupo como a cualquier otro grupo, y luego tratar al usuario no autenticado como un usuario "ficticio" que es miembro de ese grupo.

Este último parece más simple desde la perspectiva de la interfaz (API y UI) para administrar permisos. Pero el concepto de grupo público es especial parece un ligero olor a diseño. ¿Me estoy perdiendo algún principio de seguridad que haría esto indeseable?

    
pregunta jl6 08.03.2016 - 21:57
fuente

1 respuesta

2

Suena como si siguieras buenos principios de seguridad estableciendo valores predeterminados seguros, intentando que sea sencillo y asegurando que los invitados tengan el menor privilegio.

Creo que ambas opciones son viables y deberían dejarse a usted, el programador. Lo que crea que es más simple y fácil de administrar a largo plazo es probablemente la opción correcta.

Si un objeto visible to public va a ser fácil de administrar los derechos de acceso a cualquier contenido que desee, utilícelo, siempre que también proporcione una funcionalidad fácil para cambiar lo que está visible en el futuro .

Personalmente, me inclino por crear un grupo de permisos para invitados y asignarlos a ese grupo de forma predeterminada porque eso es lo que todos están acostumbrados a administrar. También permitiría que alguien administre los permisos de todos los invitados de la misma manera que uno administraría los permisos para todos los demás. Recuerde, mantenga la seguridad simple.

  

La superficie de ataque y la simplicidad van de la mano. Cierto software   modas de ingeniería prefieren enfoques demasiado complejos a lo que sería   De lo contrario será un código relativamente sencillo y simple. Desarrolladores   Se debe evitar el uso de dobles negativos y arquitecturas complejas.   cuando un enfoque más simple sería más rápido y más simple.

Lea más sobre los principios de seguridad aquí - owasp.org

    
respondido por el Pete 09.03.2016 - 00:22
fuente

Lea otras preguntas en las etiquetas