Big concern

Let's say I have a few input boxes with id's 1,2,3 respectively as a simple example.

Now I am using these ids to update certain field in my db. But what is to stop the user from editing those ids to something else! By doing inspect element in chrome.

What can I do about this. I need these ids as references to fields in my db. How do I send this to the db ensuring the user's have not tampered with it. Do I have to store these in a $_POST[] field? Or do I encrypt the ids then cross reference it in the db to get the real ids?

What do I do, what is best practice?

......

[JorgeM]

What can I do about this. I need these ids as references to fields in my db. How do I send this to the db ensuring the user's have not tampered with it. Do I have to store these in a $_POST[] field?

When the form is posted, you will access the form values via $_POST[]. Keep in mind that someone can post to your page outside of the form that you provided them via the browser. I beleive that is what you are concerned about?

Only work with the form fields you are expecting and you should always inspect the values and apply what ever business logic is necessary before sending the data to your DB. I beleive that's best practice.

[pritaeas]

Database ID's should never be exposed to users. Are you sure there is no way around this? For example storing those ID's in your session somehow. What is the reason you need them client-side?

Hi, the forms are all dynamic, for example user1 might have different inputs on their forms. Each input id therefore references a db field to insert/change.

There is no way around this as there will be so many different forms.

I can't see a way of practically storing this in a session. And if I did how would I cross reference that to the input box?

Wow I didn't realise server side validation was so complex.

The only way I can see ATM to solve this is to create a random string for each input id, then cross reference it in the db with an integer id.

E.g

Xssie22kdieksie = id 1
Kde22ldoslsekks = id 2

That way if the user tampered with the random string it wouldn't updae because it doesn't exist in the db and they could never guess the string?

[pritaeas]

That way if the user tampered with the random string it wouldn't updae because it doesn't exist in the db and they could never guess the string?

Correct.

user1 might have different inputs on their forms

From more than one record? Am just not seeing the whole picture I guess.

Prit, there are basically three stages of validation. The user, the form/project and the field values.

So I can't just say if session_id() == user1 show form1.

But the input fields also detail the version number. I don't want the end user changing the version number to something above the intended value.

So basically, I have to create random strings for EVERY single input box?

[JorgeM]

I'm not seeing the whole picture here, but I kind of understand what the process is... you are dynamically creating the input fields based on the user that is accessing the form (say a particular customer)? So, I would think that you can store the input elmenet IDs in a DB table and then when you are about to build the dynamic form server side, you perform a lookup in your DB table and retrieve the input element IDs, send that back to the browser. When the browser submits the data, you would go back to the db retrieve those IDs, and only parse those form fields.

after that, apply server side validation rules.

I'm not clear on this process in PHP, but its certainly doable using asp.net.

Am I totally off on what you are doing?

[gabrielcastillo]

I believe wordpress uses a similar process. Wordpress uses a function called nonces. numbers used once. They dynamicly insert this into form submission to make sure the post is valid. This could be something to research and find a solution.

I'm not seeing the whole picture here, but I kind of understand what the process is... you are dynamically creating the input fields based on the user that is accessing the form (say a particular customer)? So, I would think that you can store the input elmenet IDs in a DB table and then when you are about to build the dynamic form server side, you perform a lookup in your DB table and retrieve the input element IDs, send that back to the browser. When the browser submits the data, you would go back to the db retrieve those IDs, and only parse those form fields.

Yes more, or less. Unfortunately asp.net is a no go. I know this is possible with PHP and I just need to make sure the user can't really change a field with an id they shouldn't have access to.

I'm not sure how asp.net works but I would image the client side/html is basically the same and has the same issues.

I guess in my naivity I thought setting the field as readonly in html would circumvent any 'hacking' issues. Clearly this is not the case. EVERY input should be validated server side. ATM using random strings or 'nonces?' would work. I just need to work this into my current project.

[jkon]

I just need to make sure the user can't really change a field with an id they shouldn't have access to.

The sort answer: you have the user id that has being logged in your session , and as I understood you have some rules of what fields whose row’s id can update each user . So why don’t you validate that ids with the user id at the post process?

But of course pritaeas is correct when he says “Database ID's should never be exposed to users”. How to done it without ids inside the form depend on the occasion. For example, when you populate programmatically a form with fields in rows you know at that point the order of each row and the id of the row in your table. So you can store that information in your session. When you accept the post and start to process it you know the order of each field so you can easy find the id that corresponds to it.

Example script?

I agree about never exposing DB ids. Could you not have a "whitelist" formitem array for each user level and check $_POST[] items against that? I'm assuming that all users are logged in and have specific user levels (rights/privs).

I'll put together the db schema in a few hours. Maybe you can spot some obvious issues.