cleaning and re-using $_POST

[zorro]

greetings...

I'm wondering what more advanced coders would think ot this:

$_POST['myvar'] = clean($_POST['myvar']);

and now I can use POST directly:

$sql= "select * from T1 where myvar='$_POST[myvar]' " ;

function clean($var){
return addslashes(trim($var)); // whatever
}

The reason I came up with this is because i often end up calling
clean() several times on the same variable. So to avoid declaring a php
variable for each posted one, I would use an array

$arr['myvar']=clean($_POST['myvar'])) ;
$arr['myvar2']=clean($_POST['myvar2'])) ;

but since $_POST is already there, why not use it? The benefit is
simpler code, but maybe there are some security issues - that's what I
don't know.

[Rik]

zorro wrote:

greetings...

I'm wondering what more advanced coders would think ot this:

$_POST['myvar'] = clean($_POST['myvar']);

and now I can use POST directly:

$sql= "select * from T1 where myvar='$_POST[myvar]' " ;

function clean($var){
return addslashes(trim($var)); // whatever
}

The reason I came up with this is because i often end up calling
clean() several times on the same variable. So to avoid declaring a
php variable for each posted one, I would use an array

$arr['myvar']=clean($_POST['myvar'])) ;
$arr['myvar2']=clean($_POST['myvar2'])) ;

but since $_POST is already there, why not use it? The benefit is
simpler code, but maybe there are some security issues - that's what I
don't know.

My solution:
/* create array containing expected POST variables, al others are useless */
$expected = array('submit', 'text1' etc.);

foreach($expected as $var){
if(get_magic_quotes_gpc()){
$_POST[$var] = stripslashes($_POST[$var]);
}
$postvars[$var] = mysql_real_escape_string(trim($_POST[$var]));
}
And futher on I only use $postvars, $_POST is left alone.

If you just want to clean all POST variables:

foreach($_POST as $key => $value){
if(get_magic_quotes_gpc()){
$value = stripslashes($value);
}
$_POST[$key] = mysql_real_escape_string(trim($value));
}

Grtz,
--
Rik Wasmus

[Toby Inkster]

zorro wrote:

$_POST['myvar'] = clean($_POST['myvar']);

I often do such things -- why create a new array when $_POST already
exists (and is conveniently a superglobal!)?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Jerry Stuckle]

zorro wrote:

greetings...

I'm wondering what more advanced coders would think ot this:

$_POST['myvar'] = clean($_POST['myvar']);

and now I can use POST directly:

$sql= "select * from T1 where myvar='$_POST[myvar]' " ;

function clean($var){
return addslashes(trim($var)); // whatever
}

The reason I came up with this is because i often end up calling
clean() several times on the same variable. So to avoid declaring a php
variable for each posted one, I would use an array

$arr['myvar']=clean($_POST['myvar'])) ;
$arr['myvar2']=clean($_POST['myvar2'])) ;

but since $_POST is already there, why not use it? The benefit is
simpler code, but maybe there are some security issues - that's what I
don't know.

I don't like it at all.

First of all, what happens if you need to access the unchanged versions of the
$_POST variables? Maybe not now - but you might in the future. Your code may
*look* simpler - but you're just made it much harder to modify in the future.

Second, if you're calling mysql, you should be using mysql_real_escape_string
instead of addslashes.

If you're calling clean for the same variable multiple times, you should be
storing the value in a new variable the first time, then use it there. For
instance -

$myvar = clean($_POST['myvar']);

No need to call the same function repeatedly for the same data.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Toby Inkster]

Jerry Stuckle wrote:

First of all, what happens if you need to access the unchanged versions
of the $_POST variables? Maybe not now - but you might in the future.

Then you add

<?php
$origpost = $_POST;
?>

at the top of your file. :-)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Jerry Stuckle]

Toby Inkster wrote:

Jerry Stuckle wrote:

First of all, what happens if you need to access the unchanged versions
of the $_POST variables? Maybe not now - but you might in the future.

Then you add

<?php
$origpost = $_POST;
?>

at the top of your file. :-)

Hi, Toby,

Well, as you just said:

"... why create a new array when $_POST already exists (and is conveniently a
superglobal!)?"

:-)

People are used to using $_POST; adding another variable in its place makes
things more confusing. Additionally, if you ever need to merge in other
routines which use $_POST, you'll need to change that code.

The result could end being that some of your code uses $_POST and some doesn't.
This can rapidly become confusing.

And BTW, $origpost won't be a superglobal.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Rik]

Jerry Stuckle wrote:

I don't like it at all.

First of all, what happens if you need to access the unchanged
versions of the $_POST variables? Maybe not now - but you might in
the future. Your code may *look* simpler - but you're just made it
much harder to modify in the future.

I've never had the need to have BOTH the "cleaned" and the "dirty" variable.

So, with in combination the earlier posted code, you could simply make an
array of variabled to clean:

$vars_to_clean = arra('var1', 'var2', 'var3')
foreach($vars_to_clean as $var){
if(isset($_POST[$var])){$_POST[$var] =
mysql_real_escape_string(trim($_POST[$var]));}
}

Works OK for me, but then again, I haven't done that big a projects.

Alternatively, you could:
foreach($_POST as $key => $value){
$_POST['clean_'.$key] = mysql_real_escape_string(trim($value));
}

2 drawbacks:
- allthough it's possible, adding extra keys to the $_POST array isn't to my
taste...
- you'd have to guard yourself from a POST variables already beginning with
'clean_', which offcourse would become clean_clean_something... So no
checking on wether the key begins with 'clean_',

Grtz,
--
Rik Wasmus

[Richard Levasseur]

A good general rule of thumb is to leave super globals alone as much as
possible. If you do need to modify them, modify only the parts you
need. Modifying super globals is just asking for trouble when you
start introducing code that assumes (and relies on) those superglobals
are untouched. It may be a bit more work, but i think its very much
worth it with regards to input validation.

Also's:
I also don't see a difference between this and the god forsaken
magic_quotes ini option.
addslashes() doesn't escape everything necessary to make a string safe
for an SQL query (iirc, it was something in oracle or postgres)
A fun gotcha would be when you clean() something twice, but then only
stripslashes() once, giving you a nice growing list of \'s for the
users input, which is incredibly annoying to the poor guy trying to use
the form.

[william.clarke]

I leave the $_POST and $_GET array untouched and if I want to work with
the values stored in them I either stick them in individual local
variables or in a local array. That way the original values can be
referenced later if required.
One of the first rules I learned when I started programming was never
modifed passed-in variables directly, and the $_POST array and $_GET
array are essentially values passed into your script and their
super-global nature means a seemingly unrelated piece of code could be
broken by accidentally re-assigning an incorrect value to the array.

[Drakazz]

What about removing the backslashes from _GET/_POST/_COOKIE/_REQUEST
and making it a real raw variable instead of "cleaning" it.
Only "clean" things when they are in an SQL query, and you do
addslashes() with the variable. This saves you time and the magic
quotes are unessecarily in the first place (where people don't know how
to protect self from SQL injection)...

Take this for a good example:
http://de2.php.net/manual/en/functio...shes.php#60786
Initialize it at the start and then work with that. I am aware of the
"double" usage but I am also aware that you sometimes can get beaten by
the magic quotes ;] (so do it now, now later!)

[Drakazz]

What about removing the backslashes from _GET/_POST/_COOKIE/_REQUEST
and making it a real raw variable instead of "cleaning" it.
Only "clean" things when they are in an SQL query, and you do
addslashes() with the variable. This saves you time and the magic
quotes are unessecarily in the first place (where people don't know how
to protect self from SQL injection)...

Take this for a good example:
http://de2.php.net/manual/en/functio...shes.php#60786
Initialize it at the start and then work with that. I am aware of the
"double" usage but I am also aware that you sometimes can get beaten by
the magic quotes ;] (so do it now, not later!)

[Jerry Stuckle]

Drakazz wrote:

What about removing the backslashes from _GET/_POST/_COOKIE/_REQUEST
and making it a real raw variable instead of "cleaning" it.
Only "clean" things when they are in an SQL query, and you do
addslashes() with the variable. This saves you time and the magic
quotes are unessecarily in the first place (where people don't know how
to protect self from SQL injection)...

Take this for a good example:
http://de2.php.net/manual/en/functio...shes.php#60786
Initialize it at the start and then work with that. I am aware of the
"double" usage but I am also aware that you sometimes can get beaten by
the magic quotes ;] (so do it now, now later!)

I wouldn't call it a *good* example. Just someone asking about how to do
something and some suggestions.

Like William, I leave $_GET, $_POST, etc. strictly alone. If I need to clean a
value, I clean it and save it in another variable.

And you shouldn't be using add_slashes() with MySQL - you should be using
mysql_real_escape_string().

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Drakazz]

Jerry, thanks for telling me about mysql_real_escape_string
However, at least what I prefer is that the _GET and other user input
variables would be as they were sent to the browser, in the sense that
' wouldn't be escaped to \' . A good example is you trying to write to
a file :x

[Jerry Stuckle]

Drakazz wrote:

Jerry, thanks for telling me about mysql_real_escape_string
However, at least what I prefer is that the _GET and other user input
variables would be as they were sent to the browser, in the sense that
' wouldn't be escaped to \' . A good example is you trying to write to
a file :x

Drakazz,

They won't be escaped if magic quotes is off.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Drakazz]

...that's why you check ;)

[Jerry Stuckle]

Drakazz wrote:

..that's why you check ;)

No, I just don't host at places with magic quotes on. And tell my customers to
do the same.

After all - why have them on? It's overhead to escape all those chars, and more
overhead to remove them!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================