Roles de usuario: ¿por qué no almacenar en sesión?

Question

Estoy portando una aplicación ASP.NET a MVC y necesito almacenar dos elementos relacionados con un usuario autenticado: una lista de roles y una lista de identificadores de elementos visibles, para determinar qué puede ver o no el usuario.

Hemos utilizado WSE con un servicio web en el pasado y esto hace que las cosas sean increíblemente complejas e imposibles de depurar correctamente. Ahora estamos abandonando el servicio web que estaba buscando simplificar drásticamente la solución simplemente para almacenar estas cosas en la sesión. Un colega sugirió usar los roles y los proveedores de membresía, pero al investigar esto he encontrado varios problemas:

a) Sufre de problemas similares pero diferentes a WSE en que tiene que usarse de una manera muy limitada. Hacerlo complicado incluso para escribir pruebas;

b) La única opción de almacenamiento en caché para RolesProvider se basa en cookies que hemos rechazado por motivos de seguridad;

c) Presenta un sinfín de complicaciones y un exceso de equipaje no deseado;

Todo lo que queremos hacer, en pocas palabras, es almacenar dos variables de cadena en la sesión de un usuario o algo equivalente de forma segura y consultarlas cuando lo necesitemos. Lo que parece ser un trabajo de diez por minuto tiene tomado hasta ahora varios días de investigación y para agravar el problema se ha descubierto ahora que los identificadores de sesión al parecer, se pueden falsificar, ver

http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/

estoy pensando izquierda hay No es una manera fácil de hacer este trabajo muy simple, pero me parece imposible de creer.

podría alguien:

a) proveer información sencilla sobre cómo realizar sesiones de ASP.NET MVC seguro como siempre he creído que eran?

b) sugerir otra manera simple de almacenar estas dos variables de cadena para las funciones de un usuario conectado, etc., sin tener que reemplazar una pesadilla compleja con otra como se describió anteriormente?

Gracias.

Answer 1

La única manera de hacer una conexión segura es usar SSL. Algo menos que eso, y simplemente tiene que hacer la evaluación cuando sea "lo suficientemente seguro".

Una variable de sesión funciona bien para almacenar un valor, con la excepción de que el servidor web puede reciclarse de vez en cuando, lo que provocará la pérdida de la sesión. Cuando eso suceda, deberá volver a autenticar al usuario y establecer la variable de sesión nuevamente.

La variable de sesión en sí es completamente segura en el sentido de que nunca abandona el servidor a menos que específicamente lo copie a una respuesta.

Answer 2

Ha considerado la posibilidad de configurar una etiqueta de Autorización personalizada en MVC. Di un ejemplo de esto en otro question.

En la autorización inicial (pantalla de inicio de sesión o inicio de la sesión), también puede generar un valor de sesión con la dirección IP. Luego, en su autorización personalizada, también puede verificar que las direcciones IP aún coincidan. Esto ayudará a asegurar que alguien no esté 'robando' la sesión de la persona. Cada vez que accede a los datos de su sesión, solo asegúrese de pasar la IP del solicitante y controlarla un poco.

Answer 3

¿Está tratando de controlar el acceso a las funciones a nivel del cliente? Esa es la única razón por la que exponer los roles y elementos para controlar las funciones del lado del cliente.

Como alternativa, puede crear una función para obtener los elementos que las funciones del usuario pueden usar, y aun si la función se llama fuera de los elementos devueltos a la aplicación web, puede evitar que el usuario de acceder a ellos.

4Guys parece mostrar cómo controlar las funciones con los roles.

Answer 4

El enfoque que he utilizado en el pasado es utilizar el cifrado simétrico de una cookie junto con SSL. Encriptar la información del usuario en la respuesta y descifrarla en la solicitud. No estoy afirmando que esto sea infalible o 100% seguro y no me gustaría hacer esto en una aplicación bancaria, pero es lo suficientemente bueno para muchos propósitos.

El principal problema con las variables de sesión es que si las almacena en Proc en lugar de persistirlas, entonces necesita aplicar sesiones 'adhesivas' a su equilibrio de carga en un entorno de granja de servidores web. Guffa está en lo cierto al decir que sin esta sesión de persistencia las variables se perderán ocasionalmente causando una experiencia de usuario deficiente.

Las sesiones fijas pueden provocar un equilibrio de carga desigual, lo que tal vez reduzca el valor de poder escalar.

Si vas a continuar las sesiones para que todos los servidores de tu granja de servidores puedan acceder a ellas, es mejor utilizar un Guid para identificar al usuario, encriptar esto en una cookie y recuperar el registro del usuario de su almacén de datos cada vez.

Answer 5

Mi pregunta obvia es por qué quieres almacenar un rol de usuario en sesión?

Aquí está mi respuesta a su consulta, cómo esto ayuda. He adjuntado una pequeña aplicación de demostración para que mires y entiendas mis puntos. Cuando abra este proyecto en Visual Studio, haga clic en la pestaña del proyecto en la parte superior y seleccione la configuración asp.net. Desde la página que se mostrará, puede hacer las cosas de administración de usuarios.

¿Debe almacenar las funciones de un usuario de forma segura? La respuesta a esta pregunta es que no hay necesidad de que se preocupe por almacenar el rol para ningún usuario, cuando tenemos la membresía asp.net, los perfiles y el marco de roles para ayudarnos con esto. Todo lo que necesita hacer es crear un rol en la base de datos de aspnet y asignarle esa función al usuario.

A continuación, desea almacenar dos cadenas de una manera segura. Sugiero su perfil de usuario para almacenar información específica del usuario. De esta manera, tendrá la información disponible donde quiera de la clase de perfil común.

También por favor ver la aplicación de demostración adjunta colocado al final de mi blog http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx

Answer 6

almacenar información de la función del usuario en una sesión del servidor es seguro proporcionar una sesión no puede ser secuestrado. Al reiterar esto de manera más amplia, no importa dónde se almacena la información de la función del usuario si se secuestra una sesión autenticada.

Aconsejo no confiar demasiado en el artículo al que se vinculó, pero el informe del año 2002 vinculado desde su enlace es de su interés. Aquí están mis retiros:

1. No acepte las ID de sesión incrustadas en las URL.

2. Dedique su tiempo a eliminar los peligros de secuencias de comandos entre sitios, es decir, escanee todos los datos suministrados por el usuario y analice el script java ejecutable.

3. galletas problema para los dominios completos (por ejemplo myapp.mydomain.com)

4. alojar su dominio a un operador de clase alta, por ejemplo, DNS uno que solo permite cambios de DNS desde una dirección IP remota preestablecida.

5. No emite cookies de sesión persistentes.

6. Reanuda una cookie de sesión si alguien llega a una página de inicio de sesión con un sessionID ya asociado a una sesión autenticada.

7. Mejor aún, siempre emita una nueva cookie de sesión con autenticación exitosa y abandone la sesión anterior. (¿Puede ser configurado en IIS?)

Answer 7

Sólo una sugerencia, se podría considerar el uso de esta pequeña biblioteca:

http://www.codeproject.com/KB/aspnet/Univar.aspx

Tiene una aplicación del lado del servidor de la cookie mediante el cual todas las cookies puede almacenarse en el servidor mientras que la autenticación asp.net se usa para identificar al usuario. Es compatible con el cifrado y también es muy flexible, por lo que es muy fácil cambiar de un tipo de almacenamiento a otro.