Autenticación de formularios ASP.NET y autenticación persistente Cookie Security

Question

Cuando utilizamos la Autenticación de formularios ASP.NET en cualquiera de los frameworks ASP.NET (ASP.NET MVC, Web Forms, etc.), persistimos en la cookie de autenticación en el navegador del cliente . Como práctica recomendada, configuramos la cookie como HttpOnly y segura. También hacemos todas las transacciones a través de SSL. Independientemente del tipo de mecanismo que utilicemos para autenticar al usuario (OAuth, proveedor de membresía de ASP.NET, etc.), aún necesitamos persistir en la autenticación para una mejor experiencia del usuario.

Con todos estos en su lugar, supongo que alguien aún puede obtener la cookie del navegador del cliente y emitir solicitudes con esos valores de autenticación de cookies. Esto no puede ser detectado por el servidor y estaríamos dando datos protegidos a otra persona.

Creo que lo que tengo en mente para reducir el riesgo es pedirle la contraseña al cliente cada vez que intenta tomar algunas medidas serias (como cambiar la dirección de correo electrónico, acceder a la información de perfil, etc.) pero esto no resuelve nada y puede ser bastante molesto para el cliente.

¿Tiene algún enfoque que esté siguiendo activamente para este tipo de problemas? ¿O cuál sería la mejor manera de mantener la autenticación en el navegador de los clientes?

Answer 1

Estás haciendo las cosas bien para estar con él.

Si utiliza el proveedor de membresía, la cookie se marca solo como HTTP (como usted dijo) por lo que no será accesible a través del script del cliente, como una pieza maliciosa de XSS.

Si tiene la cookie marcada como segura, supongo que ha establecido el indicador "RequireSSL" en los formularios auth en verdadero. Al hacer esto, la cookie no se enviará en ninguna solicitud al servidor que no se envíe a través de HTTPS, incluso si accidentalmente ingresa una solicitud HTTP (que el navegador debe advertir al usuario de todos modos si se trata de contenido incrustado). una página HTTPS), las cookies no serán enviadas.

La única otra cosa que podrías hacer, y esto no ofrece mucha defensa además de lo que tienes, pero es una buena práctica, es usar HSTS también. Hablo de esto en OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection como un medio adicional para garantizar que las solicitudes se sigan enviando a través de un canal seguro.

A menos que se involucre en una seria reingeniería del proveedor de membresía, realmente no hay mucho más que pueda hacer. Podría vincular la sesión a una dirección IP y no aceptar solicitudes si cambia, pero esto puede causar problemas (es decir, direcciones IP que cambian y no lo protegen de varias personas en la misma dirección). También puede crear una huella dactilar del navegador (es decir, todo lo que se envía en los encabezados de las solicitudes) y asegurarse de que las solicitudes posteriores coincidan, pero estamos obteniendo detalles muy precisos aquí.

En última instancia, la seguridad debe adaptarse al valor de los activos que protege y la probabilidad de actividad maliciosa. Usted no dice qué es lo que está protegiendo, pero si se trata de un sistema financiero, llegará a una cantidad mayor que si se tratara de un simple motor de comentarios en un blog.

En resumen, parece que está haciendo un gran trabajo, solo considere la idoneidad de las medidas que ha implementado en el contexto del valor de lo que está protegiendo. Ah, y si está utilizando el proveedor de membresía de SQL para el almacenamiento de credenciales, asegúrese de leer Our password hashing has no clothes ¡y deje de hacerlo!

Answer 2

Ya está utilizando HTTPS y encriptando las cookies, lo cual es bastante seguro.

Si todavía está preocupado, le sugiero que almacene información adicional acerca de la sesión del usuario en el servidor (dirección IP, agente de usuario, etc.) y que verifique con la información proporcionada durante la sesión.

Si el usuario cambia su dirección de correo electrónico, puede enviar un enlace de revocación a la dirección de correo electrónico original, por lo que si ese cambio no está autorizado, se informa al verdadero propietario del cambio.

Answer 3

Extra en todo lo que ha hecho, y teniendo en cuenta this question Sugiero más, para mantener más información en el servidor sobre el usuario junto con la cookie de autenticación, por lo que si alguien roba la cookie e intenta usarla , también debe cumplir y todas las demás características del cliente para poder usarlo.

Parte de la información de descanso que guardo y verifico es que son lo mismo junto con la cookie de autenticación.

1. cookie de sesión conectada con la cookie de autenticación.
2. Browser ID conectado con
3. IP del usuario que está conectado con
4. Javascript debe estar permitirá

Sé que algunos se puede decir que todo lo que puede ser clon por un hacker - si el hacker puede tomar la cookie por qué no puede obtener y el resto de ellos. Bueno, nada es 100% de garantía en los escenarios y si alguien puede tomar toda la información que realmente puede tener y la contraseña es suya y de inicio de sesión, al menos lo hace un poco más seguro.