Security approach in web application

Question

Hello everyone.

I am designing a web application in ASP.NET / C# where each registered user has the ability to add/modify/delete rows based on their user-id.

Take this example:

I am going to edit my route on the page /route.aspx?routeid=854 which belongs to me (user-id: 1).

But because I am a curious guy I try to access /route.aspx?routeid=855 which belongs to another user (user-id: 2).

How can I best avoid people from accessing other peoples data? Should I send each user id (from session) with each database-call, should I validate user/password on every page load or what is the best and most secure approach?

I hope I made this clear enough.

Answer 1

Your best approach would be to send the userId to the database with the routeId to see if the user can access it.

something like:

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

If you're using something like Linq you can make a much better security model by applying the user restriction like with a reusable function like this:

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; }
}

Answer 2

DON'T REINVENT THE WHEEL

Edit: Storing UserId - you don't have to. You can get it from the MembershipProvider at any time as long as the user is logged in of course:

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

Sounds to me like you need to implement the ASP.NET Membership Provider. Have a read of this resource: http://odetocode.com/articles/427.aspx

Also, a good series from 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

In general, take this approach: Use forms authentication to validate who a user is. This is the Authentication side of security. That is, determining the user is who they say they are, usually with a username and password.

The second part of security is Authorisation, which happens once you know who the user is. This basically consists of determining which resources an authenticated user has access to. A mature system will include the following entities:

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. 

Thus, to grant a user access to routeid 854 (a Resource) you could grant the resource directly to the user or if there are multiple users who should have acceses to that resource and those users form a natural group, then create that group, grant the resource to the group and add the user to the group.

Then you can access User.Resources by a resource id or you can protect a whole page using

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

There are lots of good things available using the provider model.

Edit: Something to be aware of if you decide to store profile information about your users: The default implementation of the ProfileProvider is not particularly good. Scott Guthrie wrote a good article on a table based provider which is better: http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx