I've searched of 21000 messages in this list and I don't quite understand how to best protect user input.

Let's say you have a form that posts to itself just do see how messed up data can get:

>>>>>>>>>>>>>>>>>>>>>>
if(get_magic_quotes_gpc()) {
$_POST=array_map('stripslashes',$_POST);
}
$_POST=array_map('trim',$_POST);
$fname=$_POST["fname"];
<input name="fname" value="<? echo htmlentities($fname); ?>">
<<<<<<<<<<<<<<<<<<<<<<

htmlentities() does a good job to protecting quotes and allows for pretty flexible data entry characters.

I found another function on the internet called "cleanconvertaccents" which I can run through array_map. However it's not perfect.

If you enter an ALT-151 charcter, the value of the input keeps getting longer and longer as it double encodes on each submission.

newegg.com does a good job to maintaining extended characters (presenting them back to the user) and keeps them from getting out of hand.

How do other do this?

thanks,
-Eric Wood

On 9/12/07, Eric Wood <eric@interplas.com> wrote:
> I've searched of 21000 messages in this list and I don't quite understand how to best protect user input.
>
> Let's say you have a form that posts to itself just do see how messed up data can get:

http://php.net/filter has great easy to use functions.

depending on the type of input, i use intval() which will guarantee me
safely an integer. note that foo.php?bar=123x456 will produce 123456
(i think...) so you can't expect it will be what you want all the
time.

personally i would do this:

1) disable magic quotes
2) use filter_input() function to sanitize the input
3) then use intval() or perhaps regular expressions to scrub and
normalize the input to its expected type

i believe that will take care of everything you need.

just remember that if you use any of this data again for SQL and such,
you need to use mysql_escape_string() or other functions to escape the
data - since you've disabled magic quotes. even if you didn't disable
magic quotes it's always a good idea to use that before putting it in
any type of query.

there may be a need (you should test) to make sure that any parameters
you pass [almost] directly to sql don't allow for SQL injection. i
would think between the steps above that it can't but i haven't really
sanity checked myself on the above