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
<matt...@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
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to