Page 1 of 1
Code Snippet: $_POST => $name
Posted: Fri May 16, 2003 5:38 pm
by phice
A 2-line foreach command used to convert all POST/GET variables to regular variables...
POST:
Code: Select all
foreach($_POST as $name=>$value)
${$name} = "$value";
GET:
Code: Select all
foreach($_GET as $name=>$value)
${$name} = "$value";
The above lines will make all POST values from a form into a variable (using the value's name="") and setting it's value to the form's value (using the input's value="").
If you want to use something like: $post_INPUTNAME, then replace with:
Code: Select all
foreach($_POST as $name=>$value)
$post_{$name} = "$value";
Hope this speeds up your coding.

Posted: Fri May 16, 2003 7:08 pm
by patrikG
You could also use
extract() which does pretty much what your foreach-loops does. However, you wouldn't have that nice"$post_" in front of each variable

Posted: Fri May 16, 2003 8:00 pm
by phice
Ah, just learned something from a thread on here.
Instead of using different foreachs, just use the following code:
Code: Select all
<?php
foreach($_REQUEST as $name=>$value)
${name} = $value;
?>
Same thing with the $post_ option.
Posted: Fri May 16, 2003 10:59 pm
by McGruff
Actually that could be a big security risk. Form forging and query string tampering could send any var name with any value to your script. If a hacker knows or can guess a variable declared before the foreach line, and in the same scope as the foreach line, it will be overwritten.
Attaching a prefix like this would make it safe:
Code: Select all
<?php
foreach($_REQUEST as $name=>$value) {
${'prefix_' . $name} = $value;
}
// and if the request vars are to be stored in a db for later display in a browser I'd recommend this:
foreach($_REQUEST as $name=>$value) {
${'prefix_' . $name} = htmlspecialchars(addslashes(trim($value)));
}
?>
If you use extract, there are a few options to automatically add prefixes such as:
Code: Select all
<?php
extract($_GET, EXTR_PREFIX_ALL, "prefix");
?>
Unless you really need to declare the vars, you can save some memory by accessing the vars directly with $_POST['varname'] rather than $varname (my own preferred method). If you want to do some processing (and you do!):
Code: Select all
<?php
foreach ($_POST as $key=>$value) {
$_POST[$key] = htmlspecialchars(addslashes(trim($value)));
}
?>
Posted: Sat May 17, 2003 3:00 pm
by phice
What I do on most of my form-using php scripts, I basically do something similiar to:
Code: Select all
<?php
if ($_ENV["HTTP_REFERER"] != "http://127.0.0.1/YOUR_FILE.PHP")
{
header("location: index.php");
exit;
}
?>
...replacing
http://127.0.0.1/ with the direct URL.
big security risk
Posted: Sat May 17, 2003 6:49 pm
by llimllib
Actually, McGruff, a lot of people disagree on whether or not that is a big security risk. If the coder does proper checking of variables that they receive from the user (hint: treat them all as 'contaminated', intentionally put there to mess up your script), then it doesn't matter where they came from. And seriously, it's only trivially more difficult for me to hack up a script that will send you infected $_POST variables than it is for me to send you infected $_GET variables. Simply put, the convenience of extract() may be worthwhile, as long as you put proper thought into checking your variables for length and type.
[edit: sometimes I post before thinking. Ignore the above.]
Posted: Sat May 17, 2003 8:52 pm
by m3mn0n
Even if it is a security risk, the nice little thing phice posted is great defense for attacks.
I also use the HTTP_REFERER check on every form processing page.
Re: big security risk
Posted: Sat May 17, 2003 9:23 pm
by McGruff
llimllib wrote:Actually, McGruff, a lot of people disagree on whether or not that is a big security risk. If the coder does proper checking of variables that they receive from the user (hint: treat them all as 'contaminated', intentionally put there to mess up your script), then it doesn't matter where they came from. And seriously, it's only trivially more difficult for me to hack up a script that will send you infected $_POST variables than it is for me to send you infected $_GET variables. Simply put, the convenience of extract() may be worthwhile, as long as you put proper thought into checking your variables for length and type.
A thorough understanding of security is perhaps the most important aspect of php to learn. I am not an expert programmer by any means - and I'd appreciate it if you could help me understand your comments.
The main problem I see with extract and foreach declarations for GET and POST (without prefixing) is that a forged form or query string tampering can overwrite any previously declared variable in the same scope as the extract / foreach code - provided a hacker knows or can guess its name. Are you saying that many people disagree with that?
The other issue was a recommendation on how to process vars. Were you suggesting that there are other places in the script where checks / processing would be carried out? I must have picked you up wrong.
If a submitted var is supposed to be an integer, I would maybe just intval($_POST['var']) but, in a foreach loop, it's simpler just to do a single htmlspecialchars(addslashes(trim())) for all - works on text or naughtily hacked "integers" that aren't actually integers at all.
(Some people like to htmlspecialchars on the way out but, since I'm almost always storing the var in a db for later display in a browser, it's maybe more efficient to do it once on input rather than many times at each page view).
I guess the last link in the chain is to put all col values in quotes in a mysql query string - "integers" as well just in case they're not integers at all.
Phice: is HTTP_REFERER reliable? I've always understood that it's not - could be wrong.
Posted: Sat May 17, 2003 11:12 pm
by phice
McGruff: HTTP_REFERER is a start.
Posted: Sun May 18, 2003 12:00 am
by McGruff
rgr
Posted: Sun May 18, 2003 1:11 pm
by llimllib
Mcgruff: I must admit, I've forgotten the argument as to why register_globals was bad vs. good. It took place on the php-devel mailing list a good while ago, between two of the top developers, and I remember reading it. However, despite googling for it a good bit, I haven't been able to find it, or even which developer was arguing that it wasn't an issue. (I think it was either Zeev or Rasmus).
Anyway, the point is, since I can't counter your argument, I concede. Don't use register_globals or extract unless you're really sure of what you're doing. Sorry I posted without thinking first.
Posted: Sun May 18, 2003 7:57 pm
by McGruff
Thanks for your reply - and sorry I pinned you down like that

I had to ask so I could check I'd got it right.
With reg globals on, I suppose a pile of submitted hacker vars which aren't listed anywhere in your script would just hang around, whistling, and don't do anything except waste some memory.
I think the problem is if the hacker knows or can guess a var name. Even then, as soon as the script declares $var = foo; a hacker var with the same name would be overwritten before it gets a chance to do anything. So the only potential problem with reg globals on would be if there are any unset vars in the script.
If that's correct, and provided you're careful not to leave unset vars lying around, it would seem that reg globals on or off wouldn't matter, at least in terms of value substitution - but I guess reg globals off helps a little bit with security checks since you know where items are coming from.
Posted: Mon May 19, 2003 7:48 pm
by McGruff
An interesting point is that you could be working with reg globals off, thinking you're nice and safe, but as soon as you add some (un-prefixed) foreach / extract declarations you would be LESS secure than if you had reg globals on and no foreach / extract code (in the latter case, afaik, nothing is declared before the REQUEST vars and so there aren't any previously declared vars to overwrite).