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]