Ensuring user is updating its own record - asp.net

I'm building a simple web form which allows user to edit there data like email, emergency contact etc.
The edit form is rendered using Asp.NET MVC 5. Proper html fields are rendered for Id, email, emergency contact etc.
Lets say the request to save the data is received by the following controller method.
SaveData(recordId, email, emergencyContact)
{
;
}
Question: How do I make sure that recordId was indeed the id that was rendered as part of the edit form? We don't want this user to update another user's record.
I have the following options in mind
1. Create a hash of the record id and send the hash as well.
2. Ensure user is authorized to modify the record indicated in given record id.
Is there any other way? Does MVC 5 provide any features so that I don't have to put this sort of logic in my application logic?

Typical approaches are:
Store the ID of the record as a hidden field. If you are concerned with hijacking, encrypt the value and decrypt on the server.
Store the ID of the record in session; this way, you always pull back the record and keep the value on the server. But when session dies, so does the link to the record.
Yes I'd highly recommend check permissions to the record if you store the ID in the URL.

Related

ASP.NET How to Apply Roles & Members Read/Write Securtiy to Pages, Sections, Fields, & Records

I've built a number sites using classic ASP type security and have continued using the same methods in ASP.NET. However, I now am looking for recommendations for a better or best practice way of doing it. I've read a few resource online but have not seen anything comprehensive enough that's applicable to what I'm trying to do. What I'm trying to do is apply user specific security that determines that user's access to specific pages, sections on that page, and fields in each section. It also needs to restrict access to various records as well and determine whether it's read or write privileges.
For those interested, here's how I've done it so far:
Because I lacked the know-how, here's how I did it using the old ASP classic way...
First, on the database side I have 4 relevant tables: tblUsers, tblRoles, tblPages, tblRecords (haven't gotten to sections and fields yet). Each user can belong to a "role" and the role then determines what pages they can access as well as what records they can access in various tables (there are a number of other tables in the db as well e.g. tblCustomers, tblSales, etc...). Each table includes these fields:
tblUsers: UserID, UserName, UserPwd
tblRoles: RoleID, RoleName, UserID
tblPages: PageID, PageName, RoleID
tblRecords: RecordID, RecordTable, RoleID
Now on the application side here's what I've done:
First, my login page is based on 1) looking up the user name and password in the tblUsers table and 2) if found, setting a session variable named "UserLoggedIn" = true. Then on every page load event I check if the UserLoggedIn session is set to true, if so, continue... if not clear all session variables (log out) and send the user back to the login page. The old classic ASP way of doing it.
Second, with the login set up, to control page access, when the user is logged in I created another session variable that holds a pipe delimited string of all the pages that user can access (e.g. Session("PageAccess") = "{1|3|10|8}"). Then in each page's load event I've explicitly added a variable/constant that uniquely identifies that page (e.g. pageone.aspx has Dim PageID As String = 1). Then I check to see if the PageID matches an ID stored in the PageAccess session. If it does, continue... If it doesn't I send them to the home page.
Third/Last, for the records access, I did the same thing. When the user is logged in I created a session variable that hold a pipe delimited string of all the records the user could access along with the table it's related to (e.g. Session("RecordAccess") = "{tblCustomrs||1|5|7}" and checked it and applied it basically the same way as the page session variable.
My Solution is :(it worked for my projects)
tables : tblUser , tblRole ,
tblUserInRole : userid,roleid,username,password (this design help you can assign more than one role to a user)
tblrole, tbrules(your Access Controls for example pages)
tblRulesInRole : roleid , ruleid,Editable,Viewable,printable,Deletable
For Implement Access Control in every request and response ,you should Create HttpModule......

How to store information "per browser tab" in ASP.NET MVC?

In an MVC application I have a two pages process. On the first page we gather information that will allow us to identify which database record to update. On the second page we gather new values used to update this record. In order for this to work, we need a way to persists information between the two pages, including some record id.
I though of two way to do this and both have some problem.
Store the information in the Session object.
This works as long as the user does not open a second browser window or tab. If he does there is a risk that he'll apply the modifications to the wrong record. Suppose he opens tab 1 and complete the first step. Record id 1 is stored in the Session object. The user then open tab 2 and complete the first step. Record id 2 is then stored in the Session object overwriting record id 1. The user then come back to the first tab and complete the second step thinking he is editing record 1, but in fact he will be editing record 2.
Store the information in an hidden field on the page.
This would solve the problem solution 1 has, but it would be trivial for a ill-intentioned user to change the record id to overwrite any record.
While typing this question I just though of a third solution. That is an hybrid of theses two, but I'm not sure it's completely safe. We could store a random id in an hidden field on the page and use this to prefix the key we use to access data in the session object. I think this would work. Could this be exploited as solution 2 could?
Any other good way to securely store data "per tab" instead of "per session"?
Considering way 2 you may check security server side. If a user does not have modification rights on a specific record then server must not save it. Otherwise he/she is modifying a record that has modifications rights on it and does not matter if he/she is doing it by standard UI or hacking under it.
I think you are mixing up two things - authorization and passing data.
If user is authorized to do stuff with "another record", it's not important if he "tempers the hidden", because he is authorized to change another record as well. Nobody is going to do that intentionally. Means - you just need to check if user is authorized to do stuff in every post from the user i.e. in each controller method (and this is normal practice to always validate all user input server-side).
I would suggest you go with "hidden field".
If you want to separate info in different tabs you should use sessionStorage that differs for each open browser tab.
You can set it like this:
sessionStorage.setItem("perTabValue", "true");
Then you can get your value:
var x = sessionStorage.getItem("perTabValue");
if(x === "yourValue"){
//do anithing you want
}

asp.net 1.1 duplicated submission entries

I've got an old framework 1.1 project with the following problem: if user submits a page then in database duplicated records might appear. This error repeats often but is not consistent: in most cases there are no duplicated entries but in some cases there can be upto 4 of them. We disable submit button with JavaScript after first submission.
May be this would be helpful: there is a session object used to store user inputs (which are submitted).
Any scenarios you can think of why duplicated records can happen?
Many thanks
Finally I found that some mobile browsers ignored JavaScript that disabled submission button and users managed to resubmit form multiple times.
The easiest (?) solution to this is the following:
Create a table "SubmissionTokens" in database with two fields: Token (uniqueidentifier), DateCreated (DateTime). Then, when page with submission form loads, add a token to database and save "id" value in a hidden field on the same page. When user submits the form then read token from the hidden field and see if token exists in table SubmissionTokens. If it does exist then insert a new record with form data in the database and delete the token from SubmissionTokens. You can also use DateCreate field to expire tokens.
At work I implemented a bit different solution and just look for duplicated records in the database before inserting a new record. But this is because there is a specific requirement that user must be able to resubmit form if he clicks "back" in browser. In this case the SubmissionToken is already deleted and the first solution wouldn't work.

"Role Management" vs "User Management" in ASP.NET

Question No 1
I am familiar with role management, a particular member in a particular role can do this and access this functionally. What I need to do is Manage individual user, not the role he is in.
For example, lets say I create a role, called "Sales". I setup the role permission what the sales persons can do. Now i want to keep a check on individual user. For example if this is "john", i want to show him the records only he created. If his is peter, I want to show him only that records which he created, not by john or other sales people.
Is there a thing called "User Management" in ASP.NET that we can use? If not we have to create it ourselves and I believe the integration with ASP.NET "Role Management" will not be that smooth.
Question No 2.
I am using control for user login. I want to create a session at this time so I can keep track of which user is signed in so I can show him the records only pertaining to him. How can I do that?
Your Q1 isn't really about Role vs User management (ie: authorizations) at this point. It's about audit tracking within your application.
And the way you do that is you capture the ID of the user who created the record in question with the record, so that later you can filter on that ID.
Pseudo database structure
Table Sales
Field...
Field...
Field...
CreatedByUser int not null, -- Populate this on creation and never change it again
ModifiedByUser int not null - populate this on every row update including insert
See ASP.NET Profile Properties.
Assuming the records in the database correspond to a unique ID for a user, you can store the unique id in a profile property per user.
1) If you want to filter records by the creating user, you need to record in your table the ID of the user who created the record. You can access the name of current user through User.Identity.Name and their ID (provider-dependent) through User.ProviderUserKey.
2) Sessions are created automatically in ASP.NET and provided you have a properly configured MembershipProvider, you can retrieve all the needed user info using the User object as shown above.
It sounds like you are a little unfamiliar with ASP.NET Membership and Roles capabilities, because they are actually set up quite well to accomplish what you are describing. I would recommend checking out this tutorial series:
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
You are talking about Authentication and Authorization. For question 1 you and implement a custom authorization provider to allow for user level control http://msdn.microsoft.com/en-us/library/aa479048.aspx For question 2, once you log in and are Authenticated, the session contains a userprinciple object that has the info in it automatically.

send a mail to a user with a link

In my project i am sending a mail to the user to create a user account. I want to enable that link for the first time he/she clicks the link. if he clicks the link for more than 2 times,then it should go to custom error page.how to do this?
This depends on how the link is generated.
For example: If your link contains a username as GET-parameter, then you could simply query your database if the username is already in use. I would advise against that, because the user can easily change that GET-Parameter
I would recommend this: Your link should contain a unique identifier, most likly a hash. This hash is stored somewhere, to garantee it's uniqueness, like in the usertable of your database (a column for the hash of the registration link). That might also come handy, because you could create new user rows and already prefill them with necessary information. You could use these information upon rendering to insert text into the textboxes

Resources