¿Cuál es la reputación del marco de membresía de ASP.NET en lo que respecta a la seguridad? ¿Hay alguna configuración de configuración predeterminada típica que sea problemática? ¿Qué mejores prácticas hay? ¿Hay algún método incorporado para combatir cosas como el secuestro de sesión?¿Qué tan seguro es el marco de membresía de ASP.NET?
En lo que respecta a las mejores prácticas, hay un corto WIKI llamada ASP.NET 2.0 Security Inspection Questions que enumera las consideraciones de seguridad cuando se utiliza un proveedor de pertenencia. Puede ser de alguna utilidad?
No estoy seguro de si esto es un problema para los bits de membresía de ASP.NET per se, pero no se olvide de garantizar que haya un secreto generado en el servidor y autenticado en POST para que pueda estar seguro de que la publicación del formulario provino de su aplicación.
Puede haber otras maneras (mejor) para hacer esto, sólo estoy compartiendo lo que sé
Omar al Zabir escribió en su blog sobre algunos cambios que hizo a los procedimientos almacenados que se necesitaban para una aplicación web de alta de usuario . Su sugerencia es básicamente utilizar ya sea
WITH (NOLOCK)
o
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
antes de las consultas SELECT en los procedimientos de membresía almacenado.
Optimize asp net membership stored procedures for greater speed and scalability
buen enlace, pero eso aborda el rendimiento/escalabilidad más que la robustez de seguridad – kenwarner
cierto ... Estaba respondiendo la parte de 'mejores prácticas' ... Al volver a leer la pregunta que puede haber sido mejores prácticas para la seguridad en lugar de las mejores prácticas en general ... Supongo que no hay problema en dejar la respuesta de todos modos? –