best practice - primary_id in hidden field for input

[chidge]

Hi all,

I am wondering what is deemed the best pracice for using a primary key to get data from a mysql database.

To set the scene, I have a button and clicking that button will get information from the Database. If I place the primary_id in a hidden input in my form I can grab the information from the database simply and quickly. But does this have security implications?

I am happy with the setup of my mysql security with the connection from php to mysql, but I am wondering if it is a little dangerous leaving this value hanging in the wind... but then if I am protected it shouldnt matter.

Anyway I was just wondering what people do. Maybe I should md5 or sha1 this value (seems a little extreme)

what do people feel about having this value in the hidden input? is it a big security problem?

General advice and wisdom needed on this.

Thanks

[Fumigator]

Ask yourself, what could someone do with that value? Do you use a credit card number or email address or some other personal info as the primary key? If it's a synthetic key, I really don't see what someone would be able to do with it.

[Old Pedant]

It depends on what knowledge of the id allows somebody to do.

Let's say you are using it to view products by product id. So what if the user can view another product by just attempting different ids?

But let's say that you use an id for charging customer orders from a customer credit card table. So now somebody could order something from you and have it charged to another customer's credit card. Oops. Big time.

It's unlikely that you would design a system as in that second scenario, but there may be edge cases where something like that could happen.

If you are worried about a particular case, try to find a way around the problem. Even encoding the value may not be good enough if the hacker can use that same encoded value for another purpose. If you feel the need to encode, you should use a different key (possibly even a time-sensitive key?) for different purposes.

Generally, I try to keep all sensitive info server-side, through the use of session variables or similar. Session variables of course depend upon an id, too, but in all modern systems (ASP/JSP/PHP) the id is heavily encrypted (in a cookie or form field). And that might tell you the answer to your question.

[Old Pedant]

See, if I weren't such a windbag I could beat Fumigator to the punchline!

[chidge]

its an unsigned AUTO_INCREMENT integer. If they new the passwords, the table layout and the colum names they could do something with it, but they dont...

Thanks for the reply,

in reply to old pedant

its being used to select information about a product, this information is then placed into a session and then fed into a shopping basket. I cant really see what advantage people would get from changing this value, a different product would be entered into their shopping cart. I am happy enough with error responses that an invalid id wouldnt cause foundation showing errors...

I agree I dont like to have things on the client side that should only be server side but for this I feel I can live with it and because of other protection and the fact that much cant be done with this value bar swapping the product you want to buy I dont think its a huge concern.

[Old Pedant]

Yep. Seems quite reasonable.

[chidge]

maybe a little paranoid but I have ended up using a two way encryption class using mcrypt for this = me feeling happier about it. Thanks for the thoughts and replies

[chidge]

hmmm weird post from someone... gone now...

[Old Pedant]

Yeah, it was spam. I reported it.

Spammers make posts that are *supposed* to look like legit comments on the thread, with the purpose of getting their URLs into the thread. Very seldom are the comments remotely related to the thread, but I've seen some clever ones that are so generic you might think they are.