In asp.net mvc when updating data how does one know that the data beeing manipulated does really belong to the user making the call?

Question

In asp.net mvc when creating, updating, deleting data how does one know that the data beeing manipulated does really belong to the user making the call?

[Authorize]  
[HttpPost]
public ActionResult Edit(Model model)
{

// edit data in database

}

If a user is only to manipulate his own data but can see and easily find out information of other users witch is public to manipulate.

How can i be sure that the user is really who he says when for example Edit is called?

The Authorize only makes sure that a user has logged in.

I'm thinking about using controller.User.Identity.Name in the update to make sure the user how created the data is the one that changes it.

But then comes the question could it be possible for a user to go around this by manipulating controller.User.Identity.Name ?

How can one know that a user is who he says he is with regard to this?

Answer 1

There are two kinds of authorization.

One, which is very "vertical", has helpers provided by the framework (such as the Authorize attribute). This "vertical authorization" determines if a user is allowed to make a request or perform an action. It knows nothing of the data of the request or the action being performed, just the request/action itself.

The second, which is more "horizontal", doesn't have built-in helpers in the framework because it's subjective based on the business logic of your application. This one is up to you. This "horizontal authorization" determines if a user is permitted to manipulate specific data elements (specific records in the data) under specific conditions.

To put it simply... If a user submits a request to your application (invoking an edit action on a record for example) then while the framework can tell you if that user is permitted to invoke that action you need to manually determine if that user is permitted to edit that specific data.

For example, let's say two users create records in a table. In that table there should be a column indicating the user which created that record. (Username, some identifier, however you want to link it to a user.) This value isn't provided by the user when inserting the data, it's provided by your code when you build the record. You'd probably pull this value from the logged-in identity of the user (however you track username/id in the application).

Later, when a user attempts to edit a record in that table, you would need to validate that the user performing the action (again, based on their logged-in identity) is the user who originally wrote that record (based on the data that's in the table). Or an admin, or in some other way authorized to manage that data based on your business logic. None of this is based on values being sent from the client, it's all entirely server-side.

So while the client-side code may store an identifier for the record being edited, that value can be changed by any savvy user. That value isn't to be trusted. If a user requests a page, edits values, and submits that page then your server-side code would use the page-provided identifier to know which record the user is attempting to edit, but would use the logged-in user identity to determine if the user is allowed to edit that record. In the event that the user has manipulated the form values to edit somebody else's record, the server-side code should just respond with an error or friendly message denying that action.

Answer 2

This is a loaded question. You could do this with roles (if only Admins can edit). You can do this via user IDs (if you only want them to edit their own personal data).

It seems your question on more based on personal user data so lets go that route.

[Authorize]  
[HttpPost]
public ActionResult Edit(Model model)
{
 var userId = WebSecurity.CurrentUserId;
 var previousRecdord = //Logic or service call to get previous record
 if (previousRecord.AUthorId != userId) 
     {
       //Do Something
     }
 else
    {
      //Edit something
    }

}

You could even throw all of this into a service method and have a validate method that is called before the actions on the service are run. something like

[Authorize]  
    [HttpPost]
    public ActionResult Edit(Model model)
    {
     var userId = WebSecurity.CurrentUserId;
     var profileEntity = //some mapper that maps profile to entity
     _UserService.EditUserProfile(userId, profileEntity)

    }

and then in some service method:

    public void EditUserProfile(int userId, profileEntity profile)
{
     validateProfile(userId, profile);
     saveProfile(profile);
}

private void validateProfile(int userId, profileEntity profile)
{
 var previousRecdord = //Logic or service call to get previous record
 if (previousRecord.AUthorId != userId) 
     {
       //throw exp of some sort
     }
 }