On Fri, Dec 11, 2009 at 3:34 PM, Michael Shadle <mike503@xxxxxxxxx> wrote: > On Fri, Dec 11, 2009 at 12:29 PM, Mattias Thorslund > <mattias@xxxxxxxxxxxx> wrote: >> Kelly Jones wrote: >>> >>> If you have an HTML form select field xyz with possible values >>> "apple", "banana", and "cucumber", anyone can easily set xyz to an >>> arbitrary value. >>> >>> To prevent this, I create a hidden field code[xyz] with value: >>> base64_encode(mcrypt_ecb( >>> MCRYPT_RIJNDAEL_256,$salt,"apple,banana,cucumber",MCRYPT_ENCRYPT)); >>> >>> where $salt is stored in a file outside my webroot. >>> >>> The script receiving the POST data uses: >>> >>> mcrypt_ecb(MCRYPT_RIJNDAEL_256,$salt, >>> base64_decode($_REQUEST[code][xyz]), MCRYPT_DECRYPT); >>> >>> and confirms xyz is really one of "apple", "banana", or "cucumber". [snip] >> >> If the server-side script knows which values are expected, then there is no >> need to send that to the client (browser) and back. If this is not simply >> hard-coded in your script, you can keep it in a different file, in a >> database, or in the session, depending on your particular situation. For >> most of the fields, the number of acceptable values aren't limited to a >> small set, so it's more practical to check for expected length, data type, >> and escape the data before saving it. >> >> Cheers, >> >> Mattias > you don't necessarily need encryption, you could use digests instead > and issue a use-once ticket as well. > Why is any of this necessary? Most of the time I build select lists from arrays, so it is easy to test the value submitted by the client to make sure it exists in the array without any encryption or hashing. Am I missing something? Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
