Re: Server-side encryption to prevent form hacking: new idea?

you don't necessarily need encryption, you could use digests instead and issue a use-once ticket as well. On Fri, Dec 11, 2009 at 12:29 PM, Mattias Thorslund <mattias@thorslund.us> 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". >> >> Obviously, this can be extended to other types of form fields, and the >> check value can be a regular expression or even a function call. >> >> Is this a new idea, or have people done this before? >> > > 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 > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >