ansaurus

Question

Web Apps: Storing ID in hidden fields safe?

Answer 1

+1 A:

Storing ID in hidden value isn't quite safe. Generally, we store ID in session variable.

ppshein 2010-08-05 13:04:22

There's no need to use the session variable. It's more semantically sound (and easier) to check that user posting data has permission to edit the record they're posting data for.

meagar 2010-08-05 13:57:02

ah. meagar, u phrased what i thought very well! having 2 variables that supposedly shld store the same value, is messy and maybe prone to errors

jiewmeng 2010-08-05 14:12:05

The OP is asking how to determine what the record being edited is without it being changed, i.e how they store the ID to then post back to the server to query the record with, therefore ppshein's statement is correct. You would store the ID in a session so it can't be changed and THEN check the permissions for that record. You can't check permissions if you don't know what document is being edited.

webnoob 2010-08-05 14:35:09

@webnoob I some times open several tabs of stackoverflow with several answers/questions on the same time. You can see, that without doing loops in the air, your solution enables only one open window/tab of an edited product. Not very user friendly.

Itay Moav 2010-08-05 15:03:02

@Italy Moav Good point. On that note, surely the only true way of handling that then is to store the encrypted ID that is being used on the client side so it is posted back to the server because any way of storing it server side will result in the same problem. Would appreciate your feedback on that one.

webnoob 2010-08-05 15:36:53

@itay, good point i nv thought of that

jiewmeng 2010-08-06 06:37:00

@webnoob - if this is an item id I would never bother with encrypting it. Items ids (like here or any other system) are not to be considered secrets. You should always check in the server if user X has permissions on item Y.

Itay Moav 2010-08-06 13:56:38

You are misunderstaning what I am saying. I know the server checks for permissions; this is a must. The OP has changed and since been edited but the point it was making was how to know which document is being edited IF someone changes the value in a hidden field and then check permissions for that ID. Encrypting the ID will stop that field from changing into anything other then what you are expecting, ie. you can't just change ID 1 into ID 2 instead and you can rely on the fact that the ID that has been passed through hasn't been tampered with.

webnoob 2010-08-06 14:28:03

Answer 2

A:

It should not be based on anything submitted by the user. You should always check user permissions on server side. An attacker can prepare any request to your server.

Maciej Kucharz 2010-08-05 13:07:14

Answer 3

+4 A:

You must store some kind of id at the client-otherwise how would you know which item to edit?
This does not free you from the mandatory check on the server that the current user has privileges to edit/see the edited item.
Other then that, why would you care how he got to edit the item (whether by lawful use of the web tool, or by editing the hidden/whatever field).

Itay Moav 2010-08-05 13:07:28

jiewmeng 2010-08-05 13:22:32

it is defined in the php.ini

Itay Moav 2010-08-05 13:46:06

Well surely that would depend on which you are actually calling. $_POST or $_GET. You can then choose which one is used and as far as I was aware using global vars in that way isn't a good idea.

webnoob 2010-08-05 13:56:14

i think it shld be ok to store the id field in a hidden field as long as i check it. i have Zend_Acl in place. except that i use `$this->_getParam()`, it seems to get params from both GET and POST. and i just tested, when i have different values in GET and POST, i will get from GET. but all said, i think as long as i use the same method of getting the id i shld be safe?

jiewmeng 2010-08-05 13:56:38

Using some kind of RESTful framework this problem resolves itself; the ID of the record being edited will be included in the URL. Something like a POST request to /users/123

meagar 2010-08-05 13:58:18

Answer 4

+1 A:

as ppshein said, storing sensitive ids in a hidden var is NOT safe. Would you store a password in a hidden var? Its really easy for even a novice hacker to get that data.

You need to make sure that all access control is enforced by the server.

in your case, you need to make sure that the user who is logged in (the one on the session) is the owner of the profile being edited. Or that the user who is making the edits has permissions to edit that profile (e.g. is an admin)

hvgotcodes 2010-08-05 13:08:51

Answer 5

A:

Agree with all the points above but if you really do need to store something clientside for whatever reason, you can always encrypt the data and decrypt when you need to use it but again, using sessions would be the best way to deal with it as they are not accessible client side.

webnoob 2010-08-05 13:54:24

that doesn't change the fact that the user can change the value tho.

jiewmeng 2010-08-05 14:13:52

Of course and that is where the server side validation comes in. If a hacker changed a value in an encrypted ID, then it would no longer decrypt correctly and therefore you would know something was wrong.

webnoob 2010-08-05 14:32:29

then i think the encryption may not be too useful in this case as the id isnt a secret. encrypt or not, i will still need to check if the user has access to the resource requested.

jiewmeng 2010-08-06 06:40:19

also regarding your comment on @ppshein's post, i think i cant rely on a decrypt-able hash as a valid request. if somehow, the user knows your hashing method, he can create valid hashes to use.

jiewmeng 2010-08-06 06:42:50

The user wouldn't know. That is the whole point of encryption (not hashing). You have a key stored in script somewhere (or somewhere else) and you use that for the encryption and decryption. You can have different levels of encryption as well (up to 256 bits (maybe more, not sure - never gone higher :)) If you need to show something client side, encryption IS the best way to do it.

webnoob 2010-08-06 07:24:35

I know the ID isn't a secret, the point is that you stop the user changing the value. So you know you are checking the permissions on the correct document server side.

webnoob 2010-08-06 07:33:17

ansaurus

tags:

views:

answers:

Web Apps: Storing ID in hidden fields safe?

related questions