extract($_POST);
Moderator: General Moderators
extract($_POST);
Can you incorp things like:
htmlentities(stripslashes());
around
extract($_POST);
Thanks
htmlentities(stripslashes());
around
extract($_POST);
Thanks
Re: extract($_POST);
I'm not sure I follow, but are you asking if you can do something like htmlentities(stripslashes(extract($_POST)));Jim_Bo wrote:Can you incorp things like:
htmlentities(stripslashes());
around
extract($_POST);
Thanks
You can, but it doesn't make much sense because extract returns an integer of how many variables it produces.
-
Well, you would have to loop through all POST (GET, COOKIES) variables/indexes:
djot
-
Well, you would have to loop through all POST (GET, COOKIES) variables/indexes:
Code: Select all
foreach ($_POST AS $key => value) {
addslashes($_POST[$key]);
}-
Sometimes array_walk may be of intrest too...
I cant get any of the 2 functions to work ..
should array_walk be something like:
array_walk($_POST, addslashes); or array_walk(addslashes($_POST));
?
Thanks
should array_walk be something like:
array_walk($_POST, addslashes); or array_walk(addslashes($_POST));
?
Thanks
Last edited by Jim_Bo on Tue Jan 03, 2006 2:21 pm, edited 1 time in total.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
- trukfixer
- Forum Contributor
- Posts: 174
- Joined: Fri May 21, 2004 3:14 pm
- Location: Miami, Florida, USA
extract() is *EVIL* anyone can make a form and set any number of post variables such as $_POST['admin_is_logged_in'] = true; or any number of other things, and extract will simply assume and accept *any* post value and assign it to a variable of that name..
You would be better off to *NOT* be lazy , and specifically call the post values as you need them , (starting with checking them for evil injection stuff) such as
$main_page = $_POST['main_page'];
Your code will be much more secure than if you used extract().
You would be better off to *NOT* be lazy , and specifically call the post values as you need them , (starting with checking them for evil injection stuff) such as
$main_page = $_POST['main_page'];
Your code will be much more secure than if you used extract().
The error I get using array_walk ($_POST, 'addslashes'); is
Warning: Wrong parameter count for addslashes() in #:\###\htdocs\login\profileparse.php on line 5
Hmmz ok .. wasnt so much about being lazy .. just thought I could get away with alot less code than I have using extract()
So am I seriously best to leave it alone and go the long way around? Is this the same risk for array_walk()?
Thanks
Warning: Wrong parameter count for addslashes() in #:\###\htdocs\login\profileparse.php on line 5
Hmmz ok .. wasnt so much about being lazy .. just thought I could get away with alot less code than I have using extract()
So am I seriously best to leave it alone and go the long way around? Is this the same risk for array_walk()?
Thanks
- trukfixer
- Forum Contributor
- Posts: 174
- Joined: Fri May 21, 2004 3:14 pm
- Location: Miami, Florida, USA
pretty much the same risk - GET, POST, COOKIE, REQUEST, GLOBALS,and SERVER and in certain situations, even SESSION, globals can and often are easily modified and messed with (even in realtime via proxy server) - Basically, it is *all* what is known as "user provided input" .. and the rule of thumb is NTUI - Never Trust User Input ... just because you have a form with two POST values and nothing else, does *NOT* mean that you will *only* have two variables written in the next page using extract
For example, maybe you want a username and password, and in your code you happen to include a config file which has the admin's password like $adminpass = 'anypassword'; and a user was to create his own form and send it to your server, and you used extract , if the extract of post data happens *AFTER* the config file is included, $_POST['adminpass'] will overwrite $adminpass , and suddenly for that particular login, a user could very easily break in to admin area , unless you check for such a possibility very carefully ..
Even though your form was just $_POST['user'] and $_POST['ppass'] , the $adminpass variable from config.php would be overwritten (as would any other variables that were brought in before you do the extract() ) because the user made his *OWN form on his own webserver and POSTED all that data to your form, so that user could send you a form with 15 - 20 POST parameters and extract will gleefully take every single one of them , create a variable by the post field name, and assign it the value it was given in the input - or overwriting variables thaat you had already included before you run the extract();
it's basically the same results as doing foreach($_POST as $key=>$value) .. it's just plain evil, and anyone using these are just asking for headaches , IMHO .. do it the right way and keep total control of every variable (that also means not setting variables global , and coding your app to work with register_globals = off, if you can possiibly help it) , and you will be happier in the long run , once you get your applicatin out of development and into the real world...
Spend an extra 10 minutes writing out a specific request and assignment for evey post value that you will be using, and anything else sent via POST will be ignored .. this puts a very nice limit on the data you will be having to deal with, so you will be able to work within known parameters that you set with a reasonable assumption that you wont have oither stuff being sent that could overwrite some important variables..
there are fast coders, and there are secure coders, but very vew fast,secure coders , IMHO
even when I have a form that accepts as many as 100 different fields from a POST'ed form, I will specifically call em into my code.. it takes more time than simply doing an extract($_POST) , but I also know I'll have far fewer "holes" where someone could overwrite one of my variables
Bri!
For example, maybe you want a username and password, and in your code you happen to include a config file which has the admin's password like $adminpass = 'anypassword'; and a user was to create his own form and send it to your server, and you used extract , if the extract of post data happens *AFTER* the config file is included, $_POST['adminpass'] will overwrite $adminpass , and suddenly for that particular login, a user could very easily break in to admin area , unless you check for such a possibility very carefully ..
Even though your form was just $_POST['user'] and $_POST['ppass'] , the $adminpass variable from config.php would be overwritten (as would any other variables that were brought in before you do the extract() ) because the user made his *OWN form on his own webserver and POSTED all that data to your form, so that user could send you a form with 15 - 20 POST parameters and extract will gleefully take every single one of them , create a variable by the post field name, and assign it the value it was given in the input - or overwriting variables thaat you had already included before you run the extract();
it's basically the same results as doing foreach($_POST as $key=>$value) .. it's just plain evil, and anyone using these are just asking for headaches , IMHO .. do it the right way and keep total control of every variable (that also means not setting variables global , and coding your app to work with register_globals = off, if you can possiibly help it) , and you will be happier in the long run , once you get your applicatin out of development and into the real world...
Spend an extra 10 minutes writing out a specific request and assignment for evey post value that you will be using, and anything else sent via POST will be ignored .. this puts a very nice limit on the data you will be having to deal with, so you will be able to work within known parameters that you set with a reasonable assumption that you wont have oither stuff being sent that could overwrite some important variables..
there are fast coders, and there are secure coders, but very vew fast,secure coders , IMHO
even when I have a form that accepts as many as 100 different fields from a POST'ed form, I will specifically call em into my code.. it takes more time than simply doing an extract($_POST) , but I also know I'll have far fewer "holes" where someone could overwrite one of my variables
Bri!