CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-3
SamJolly
SamJolly

Reputation: 6485

MVC3 and URL Tampering

Quite a lot of posts on this one, especially : SO Question:URL Tampering

Which contains some interesting approaches.

I am looking for a pragmatic approach, some of which are contained in the above post. I admit I have come to this issue a little late in the development of my application. My URL have the traditional controller/action/id format by and large, so are easy to tamper, as I now realise, and also for other user records. My ids are integers, this might have been a mistake. Would GUIDs have been more secure?

Validating the DB queries more extensively using the current user id is also an option ie only return data is owned by current user. Flip side to this means modifying quite a few queries.

I am also using membership services with MVC3/EF4.1/SQL Server 2008.

Many thanks for any suggestions.

Upvotes: 0

Views: 151

Answers (1)

Darin Dimitrov
Darin Dimitrov

Reputation: 1039598

You seem to be talking about resources and users in your application. So I suppose that you have authentication where users are supposed to manipulate the resource that belong to them. And your issue is that by replacing the id in the url, the current user could manipulate the resource of another user which he is not supposed to do.

The proper way to solve this is not by hiding ids from the url but rather by using authorization. So you could write a custom AuthorizeAttribute which would get the currently authenticated user and the id and then verify in the database (or wherever you store this information) that this id belongs to him. Then by the time he hits the controller action you will already know that the current user is authorized to do whatever he asked to do with this resource.

You may take a look at this post of mine in which I exemplified the approach.

So when dealing with such scenarios always think of the fact that the only artifact that the user cannot manipulate is his authentication ticket. So the only insurance you get is who the current user is. From this fact on, you should perform the necessary authorization based on your custom logic.

Upvotes: 4

Related Questions