Hidden fields are very, _VERY_, insecure, people can (and do) modify them. All they have to do is to save the form, edit it with their favorite text or HTML editor, load them in their browser et voila! They can now use the modified form with a field of their own. You really can't use this for any security related purpose. The only thing you can do is use a hidden field to store a session ID (random enough so people can't guess it), but even this can be intercepted and used to highjack a session.

Basic HTTP passwords are nearly as insecure, they are exchanged in an ecoded (but not encrypted) form, that's so close to clear text that it might as well be (something like BASE 64 encoded or something equally easy to decode). You can't rely on this either, unless you don't care much about what you are giving access too.

Of course if you are behind a firewall you can decide to trust your users, as they can be fired if they misbehave. If you really want the system to be secure you will have to use a secure protocol, usually HTTPS. You will just have to setup an HTTPS server.

Hi,
Thanks for your reply(and to everyone else who replied)
In the last paragraph you mentioned secure servers.
Does all data that's sent through a secure server have a higher
level of encryption? Is it still possible for people to edit
the hidden variables in a form and send it back to the server.
And one final question whats is an ecoded form? And whats the
difference between a ecoded form and an encrypted form.
Thanks again for your help in advance.

Anthony

"ecoded" is a typo, and I am surprised chipmunk did not notice it ;--( When I (tried to!) use "encoded" on the other hand I meant that although the data is not transmitted in clear text anybody can decode it without needing a secret password. I would use "encrypted" for data that, even if intercepted by evil creatures, could not be made sense of without additional information (a private password).

In your case, if you don't trust your users the "hidden field holding the user name" trick will still be dangerous as a "legal" user could then guess another usrs login, change the form and act as if it were the other user. But regular authentication using a .htaccess file would work just fine I think.

If the FORM uses the GET method, then the variables will be visible in the Location bar of the browser; A user could then simply edit them.

If the FORM uses the POST method, the user can save the page to their hard drive, edit the source to change the values, then submit from that edited version of the page.

Short answer -- Yes people can see and change values in "hidden" form variables.

Just to add a strategy you might employ to deal with the fact that hidden form fields aren't really a form of security (they're more for the convenience of the user and the programmer than anything else).

If you know in advance which fields are going to be hidden, you can generate an MD5 hash (see Digest::MD5) of that data which will serve as a 'fingerprint' of the values in those fields. You should generate this fingerprint by concatenating all the strings that end up in those fields with a value the user never sees, so it's not so easy for the user to fake your program out by generating their own hash.

Save that value away when you generate the form, and compare it to the MD5 fingerprint of the data that actually gets submitted. Of course, you'd need to be able to link the submitted values with the form that was generated. That would require generating a (random as possible) ID for the form: e.g. the form gets the ID (stored as another hidden field, purely for convenience) '120897af987dfaf6kl3h4987', and you can store that key in some sort of database (a flat file will do for simple setups), along with the data fingerprint. By the way, MD5 is good for generating these IDs, too!

This is a variant on the session ID strategy that mirod mentioned; it has a *slight* advantage over the session strategy in that the sessions are *so* short (really, they last for just two HTTP requests) that the possibility of hijacking virtually disappears.

Hmm, that's a lot of stuff there. If I confused you (I confused myself a bit!), feel free to /msg me in the chatterbox.

perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); 
+$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth
+er_name\n"'
[download]

Link fixed or updated or something: Web Client Programming with Perl