Are hidden inputs safe?

Vigilante

As I understand it is possible for a user to change the value of a hidden input before POSTing to the server.

My questions are: Is there a java method or php authentication method of preventing this from happening?
How does a user do this? If this is true, just what good are hidden inputs?

dalecosp

Originally posted by Vigilante
As I understand it is possible for a user to change the value of a hidden input before POSTing to the server.

<curious>From what source did this understanding come? </curious>

It is quite possible to alter variables by submitting them in the URL "GET"; would this supersede POST vars from hidden fields?

planetsim

yes its possible if someone copy's your site that has a form. Then change some code then use it.

It'll be changed.

dalecosp

Originally posted by planetsim
yes its possible if someone copy's your site that has a form. Then change some code then use it.

It'll be changed.

Hmmmm, good call. Never read that before, but since HTML source has to go to the browser, it makes perfect sense. Thanks to both of you for this educating point.

Now, back to the OP's question: what to do about it? I've got a few <INPUT TYPE=HIDDEN> vars myself.....

Vigilante

http://www.eweek.com/print_article/0,3668,a=34324,00.asp

Is there an .htaccess or other method of preventing a form from a domain other then the one where the script is supposed to be run from accepting it's variables?

If someone copied my forms and changed input type=hidden to input type=text and changed IDs to hack me they should need to have their scripts on my server, no?

kinadian

May I assume that you are all worried about this because it will affect your database? I can't really think of other reasons to be concerned.

MySQL (at least on linux) can restrict access to certain hosts. For example, I have a 'phpuser' login to my MySQL server from 'localhost'. I also have a login for my desktop's host with the same username and password. Any other host attempting to connect (even if they have the correct username and password) will be unsuccessful. In fact, I was myself (from my desktop) until I noticed this and added the new user.

So if you restrict your access to localhost, (I rarely use my desktop to connect to my database) and just SSH into your server to run the MySQL client from there (for backend database access), you should be fine. Even if someone gets your script and attempts some malicious scripts.

If there is another reason to protect your hidden values, may I suggest session variables?

--kinadian

dalecosp

Originally posted by kinadian
May I assume that you are all worried about this because it will affect your database? I can't really think of other reasons to be concerned.

In my case, 'cause I'm newbie enough that values somewhat critical to site management functions are in HIDDEN input fields. Now, to be sure, these pages are login-protected, but I'm paranoid, and so far paranoia has worked (I'm also owner of several 24/7 'Nix boxes).

If there is another reason to protect your hidden values, may I suggest session variables?

--kinadian

Sounds good, it's only the nth time today I've told myself I need to RTFM on them, but I'm coding against a deadline at the moment...it may need to wait for "2.0"......

kinadian

Here:

This is want basically explained sessions for me.

http://www.webmasterbase.com/article/319

I needed to talk to a guy at work too to answer a couple little questions I had. Such as:
You can think of sessions as cookies on the server.

You need to have session_start() on every page you wish to access the session variables.

There is a cookie placed on the client machine that only contains the session id (which is a big number).

Let me know if you need anymore assistance.

--kinadian

dalecosp

Originally posted by kinadian
Here:

This is want basically explained sessions for me.

http://www.webmasterbase.com/article/319

I needed to talk to a guy at work too to answer a couple little questions I had. Such as:
You can think of sessions as cookies on the server.

You need to have session_start() on every page you wish to access the session variables.

There is a cookie placed on the client machine that only contains the session id (which is a big number).

Let me know if you need anymore assistance.

--kinadian

Thanks!! I also note that at this site, at least, the sessionID is appended to the URL as a GET in most cases......

dotbob

You're worried about someone modifying a copy of your form to enable them to change the posted data?

Easy, just check the referring IP address in the page that you post to.

For example, let's say that your server (where your site is hosted) has an IP address of 192.168.254.1 (yes I know this is an internal address before anyone says so), do the following:

<?
$my_server_ip = 192.168.254.1;

if($_SERVER['REMOTE_ADDR'] != $my_server_ip)
{
echo "Unauthorised page access outside of domain";
}
else
{
//execute rest of page content here.
}
?>

ahundiak

If only life was so simple.

There are plenty of tools which allow users to modify the html code and then resubmit the form back to the server as though it was coming from a browser. And there is absolutely nothing you can do about it.

$POST,$GET and $_COOKIE variables can all be hacked. And you don't need any server rights.

Back in the good old days, store sites would send prices out to the users as hidden data. The bad users would edit the price and suddenly get a $100 item for $1.

Never trust any data coming back from the user. Always validate on the server.

dotbob

here here!🆒

Vigilante

I've been reading on this topic and I thought I should mention that ENV variables are just as unsafe as get post and cookie vars.

In other words, a check of REMOTE_ADDR and HTTP_REFERER is useless.

This is not good for me. I've been using hidden inputs to hold item IDs that are being edited. Not for user account necessarily because those get their IDs right from the database but my system allows users to edit posts and stores the post ID in a hidden field. They could edit other people's posts.

So, talking about validation, I guess I would just have to make a couple sql queries to verify that the post id a user is trying to edit belong to that user. Fair enough, but there goes my pipe dream of having the same bit of code do it all.