Guys i'have a question.
I'm currently buiding a wizard that has 5 step's until being completed.
The user starts by the first step where he generates the entry id.
From there on i start passing the id over the url like this:
host.com/{controller}/{view}/{id}
This is how my url looks like after the step1,
------- currently at view step2 passing the id=120
host.com/{controller}/step2/120
This isn't safe because as you know, anyone can change the id and affect other users's entries. Ofc, it can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Now, my question is... is there a better way to do this?
Any tips for future work?
Is what i'm doing enougth?
(begginer doubt praying for a expert awnser)
Cheers
...It can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Yes, that's true. You should start there.
Here are some other things that you could do:
You could make your entry ids Guids instead, so that a would-be hacker would never try to guess an entry id.
Because using GET for sensitive data is a bad idea, you could, as endyourif suggests, pass the entry ids with hidden fields instead.
If you are truly concerned about the user altering the ID in the URL, then you must spend the additional time adding an "isOwnedBy" like functionality.
As an additional security measure, you could pass it via a hidden variable in the form so it is at least not as easy to change as well.
Edit: I like #LeffeBrune's suggestion of encrypting the idea as well. However, I still suggest that the validation is performed on the function to ensure the user owns the object. It's just good practice.
Related
VS2013, MVC5
I was reading another SO post to solve a record updating problem (I did solve it thanks to the post). But in studying the many answers and comments on this post I found one that caused me pause. link.
The comment is by Serj who comments that putting a UserID as a hidden item in the Edit form is a security flaw. I understand his post and it makes sense we wouldn't want to expose anything we don't need to.
But it made me think about my particular Edit view I was working with. I am creating Role management for my MVC5 site and I'm passing my Role ID through the Edit page. Now that Id is not an integer like many tables have, but rather a long string that I assume was done for security purposes. But it's the primary key for the record and I don't see how I can avoid not passing that Id through the Edit page.
So I thought I would ask if I'm not thinking this through clearly, or it is a risk but there's nothing I can do about it?
If I should not expose that Id, how would I edit the Role table without passing the record's Id?
So I thought I would ask if I'm not thinking this through clearly, or
it is a risk but there's nothing I can do about it?
Yes, it's a risk. Just because the id is hard to guess doesn't mean that you are safe. You should never expose such information without performing the necessary validation steps on the server.
If I should not expose that Id, how would I edit the Role table
without passing the record's Id?
You should pass the record Id, that's for sure, otherwise you will never be able to edit anything. But on the server you should verify that the currently logged-in user has the necessary permissions to modify the roles for this particular id.
In my Rails App, I made a form_for to allow any visitor to submit their content.
But after submit, I want to ask user, whether they want to register for this site or not.
There are some approach to this:
Redirect after user submits the form, left the initial post anonymous.
Much the same as the first one. But somehow help user to reclaim the post they just make
Store the content in some place first and do not submit. Instead, ask for register. And after register, show the stored content before and ask user to submit again.
Basically, I can implement the 1st method. But it seems just not that good. For the 2nd and 3rd one, I do not know how to reclaim the post or store content beforehand.
Is there a standard way to do this? How can I solve this problem?
For solving the same kind of problem, I chose your 3rd option. For that you can use sessions, it will allow you to keep some information in memory related to a specific connection to your server.
http://guides.rubyonrails.org/action_controller_overview.html#session
There are some ways.
First of all you need to keep in mind that these are different behaviors from which you should chose first and do not let the implementation force you to chose one.
For the second case you can have the id of the post that was created (along with some guarantees that it is an orphan post) and then tweak your register method to also assign a post to a user after creating one.
The Third case can be implemented by storing the post data either to session or to a backend temporary store and retrieve them if needed.
For one of my project's (weird) requirements, I want to use cookie less sessions. At the same time, "session.use_trans_sid" can not be turned on :(
Does anybody please let me know if is there any other way out ??
Thanks
Manish
Make a custom session manager that identifies the user based on, for example, IP address and user agent and other identifying factors (as IP+UA might not and probably will not be unique). Another (ugly) solution is to just implement the use_trans_sid functionality yourself by adding a session identifier GET parameter to every link by hand (if it's a small site) or with a hidden form (that's non-standard).
If you really want sessions without cookies, you can always put the SID in all your URLs manually. People used to do this quite a bit. :-)
The only other option is to keep the session data on the client and pass it back and forth to and from the server with each request, although technically that would be a sessionless architecture.
That means that for GETs each link has to be rewritten to include all the session variables, and for POSTs they have to be included as hidden fields.
We have been using asp.net mvc for development. Sometimes, we need to put some hidden fields on form that are shoved in the model by modelbinder (as expected). Nowadays, users can easily temper the form using firebug or other utilities. The purpose of hidden field is mostly to provide some information back to server on as is basis and they are not meant to be changed.
For example in my edit employee form I can put EmployeeID in hidden field but if user changes the employeeID in hidden field, wrong employee will be updated in the database. in this scenario how can we keep the integrity of hidden fields.
You need to enforce security to ensure that the person doing the modification has permission to do so. I'd also put the id in the URL typically rather than a hidden field, relying on the security to ensure that people don't modify things that they shouldn't be able to. If they do have permission to modify the item when changing the id manually, it shouldn't be a problem. The important thing is to make sure that a person can't change the id manually and get access to something they shouldn't. Enforcing server side permissions solves this problem. You can easily do this using Roles in conjunction with the AuthorizeAttribute.
if user changes the employeeID in
hidden field, wrong employee will be
updated in the database
This is a major security hole in your website. In everything you do with web development, no matter how clever someone's code might be or how much you think you'll be ok as long as users don't do something, remember one golden rule: Never implicitly trust data received from the client.
In order to modify anything in your website, the user must be logged in. (Right?) So in any attempt a user makes to post a form to the website (especially one which can modify data), double-check that the user submitting the form has permission perform the action being requested on the data being specified.
Ideally, every action which isn't completely public and unsecured should have a server-side permissions check. Never, ever trust what the client sends you.
One potential alternative would be to store that static, single-use information in TempData on the server and not pass it to the client where it could be tampered with. Keep in mind that by default TempData uses Session and has limitations of its own - but it could be an option.
I'm designing (and developing) web software that will allow the general public to sign up for a service, become a customer, and exchange fairly sensitive data.
I'm working through the documentation and the tutorials, and of course the RESTful pattern adopted by the default routing in ASP.NET MVC is to do URL's like this: /customer/edit/3487.
I guess I am a little squeamish about displaying such technical details as customer ID in the URL bar.
What do the smart kids do these days? Does RESTful have to mean "put your record ID's on display"?
Edit: In an ASP.NET WebForm I would have stored this in the session, I think. But I'm finding that this is discouraged in ASP.NET MVC.
Edit:
I do not intend to rely on security through obscurity.
That still doesn't mean its a good idea to give the users any ideas, or any information about the underlying data. Let's say I have an app that's publishing information about the different business in a Chamber of Commerce, to be arbitrary. Once you are logged in, you have an administrative right to click on every business in the directory and see them all - but the application is supposed to spoon feed them to you as search results or the like. Just because the user technically is allowed to access all records, this doesn't mean it should be trivial for you to write a screen scraper that downloads all of my content in a few minutes. As well, the user can just look at customer ID's and make a guess about how many customers I might have. There's lots of good reasons not to display this.
As long is there is proper authentication and authorization being done on server side then displaying ids is not an issue.
Otherwise just try to encrypt the particular id or username in the URL, this way it will be difficult for the attacks.
You don't have to put the Id in the Url, you just need to use a unique value or unique combination of values to find the data you want to display.
I'd think that the actual bussinesses name would be good and also look good in the Url. So you would have something like this:
/Business/View/theouteredge/
Or if the business name is not unique you could use a combination of business name and zip/postal code.
/Business/View/theouteredge/78665/
You would have to write a new route to handle this.
routes.MapRoute(
"Bussiness",
"Business/{Action}/{name}/{zip}/",
new { controller = "Business", action = "Index", Name = "", PostalCode = "" }
);
All this action would need to be secured with the [authorize] attribute, or the controller its self.
If you also decorate your actions with [authorise] then if another user does use the id from another user, they will automatically be challenged for a login.
It's 6 of one and 1/2 dozen of the other as to whether you use an ID or a Name. Eventually they both resolve to a record.
The important thing is to only allow authorised persons to view the data by allowing them to log in.
I've got a site which has sensitive data but only if you are the holder of that info can you see it and I do that by decorating my actions and checking rights etc.
I think that putting an ID in a url is fine -- as long as it is a Surrogate Key. The key has no value, except to identify a record. Just make sure that the requester is authorized before you send sensitive data back to the client.
Update:
I can see how having a number as part of your URL is undesirable. After all, a URL for a web app is part of the user interface, and exposing such internal details can take away from the UI's elegance. However, you are faced with limited options.
Somehow, you have to identify the resource that you want to get. The crux of REST (IMO) is that a request to a server for a particular resource must be described entirely by the request. The key for the item you want has to be encoded into the HTTP GET somehow. Your options are: put it into the URL somehow, or add it to a cookie. However, adding a key to a cookie is frowned upon.
If you look at this site you will see the question id in the url. If you view your profile you will see your username. So you would probably want to use usernames intead of an id.
If you're really concerned about it you can use a Guid, which isn't very user friendly but would be very hard to guess. :)
If you use some other way than customer id simply because you're concerned about security, then that means you're using security through obscurity, which is a bad idea. Proper authorization would require something like you either 1) have to be logged in with that customer id, or 2) be logged in as an admin, to have that request succeed.