Enfoque de seguridad en la aplicación web

Question

Estoy diseñando una aplicación web en ASP.NET/C# donde cada usuario registrado tiene la capacidad de agregar/modificar/eliminar filas en función de su id de usuario.

Tome este ejemplo:

voy a editar mi ruta en la página /route.aspx?routeid=854 que pertenece a mí (identificación de usuario: 1).

Pero debido a que soy un tipo curioso trato de acceder al /route.aspx?routeid=855 que pertenece a otro usuario (ID de usuario: 2).

¿Cómo puedo evitar que las personas accedan a los datos de otras personas? ¿Debo enviar cada identificación de usuario (de la sesión) con cada llamada a la base de datos, debería validar usuario/contraseña en cada carga de página o cuál es el mejor y más seguro enfoque?

Espero haber aclarado esto.

Answer 1

NO REINVENTAR LA RUEDA

Editar: Almacenando UserId, no es necesario. Se puede conseguir desde el MembershipProvider en cualquier momento, siempre y cuando el usuario se registra en claro:

MembershipUser user = Membership.GetUser(); 
Guid UserID = user.ProviderUserKey; 

Me parece que es necesario implementar el proveedor de pertenencia de ASP.NET. Tiene una lectura de este recurso: http://odetocode.com/articles/427.aspx

Además, una buena serie de Scott Guthrie: http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx

En general, toma este enfoque: Uso de autenticación de formularios para validar que un usuario se encuentra. Este es el lado de Autenticación de la seguridad. Es decir, determinar quién es el usuario es lo que dice que es, generalmente con un nombre de usuario y contraseña.

La segunda parte de la seguridad es la Autorización, que ocurre una vez que se sabe quién es el usuario. Básicamente, esto consiste en determinar a qué recursos tiene acceso un usuario autenticado. Un sistema maduro incluirá las siguientes entidades:

User: may contain extended profile information captured on registration 
Resource: a page or other resource that can be restricted. 
Group: a group of users who can access resources due to their group membership (groups are granted resource access) 
Role: a type of user such as Administrator/Developer/Salesperson. 

Por lo tanto, para conceder a un usuario acceso a routeid 854 (un recurso) se podría conceder el recurso directamente al usuario o si hay varios usuarios que deben tener Accesos a ese recurso y esos usuarios forman un grupo natural, luego crean ese grupo, otorgan el recurso al grupo y agregan al usuario al grupo.

A continuación, puede acceder User.Resources por un identificador de recurso o puede proteger una página entera usando

if(!User.IsInRole("RoleName")) 
{ 
    //redirect to access denied page 
} 

Hay un montón de cosas buenas disponibles utilizando el modelo de proveedor.

Editar: algo a tener en cuenta si decide almacenar información de perfil sobre sus usuarios: la implementación predeterminada de ProfileProvider no es particularmente buena. Scott Guthrie escribió un buen artículo sobre un proveedor basado en tablas que es mejor: http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

Answer 2

Su mejor enfoque sería enviar el userId a la base de datos con el routeId para ver si el usuario puede acceder a él.

algo como:

select * from route where routeId=@routeId and userId=@userId 

Si está usando algo como LINQ se puede hacer un mejor modelo de seguridad mediante la aplicación de la restricción de usuario como con una función reutilizable como esto:

public Route Get(int routeId, int userId) 
{ 
    var query repository.Get<Route>().Where(r => r.Id == routeId); 
    query = applySecurityModel(query, userId); 
    return query.FirstOrDefault(); 
} 

private IQueryable<T> applySecurityModel<T>(IQueryable<T> query, int userId) where T : ISecurable 
{ 
    return query.Where(t => t.UserId == userId); 
} 

public interface ISecurable 
{ 
    int UserId { get; set; } 
} 

public class Route 
{ 
    int Id { get; set; } 
    int UserId { get; set; } 
}