Can't access your variables?? Look here!!!
Moderators: egami, macek, gesf
PHP 4.2.0 (and later) have disabled the register global settings by default, for enhanced security. What does this mean for you?
Instead of accessing your server variables (ie GET,POST,COOKIE,SESSION,SERVER etc) variables directly, or by using the $HTTP_POST_VARS etc arrays, you will have to call them directly from their Super Global Arrays
PHP 4.1.0 introduced SGAs, which is a more secure way of accessing your variables to prevent hacking. Instead of access a 'GET' variable using $getVar or $HTTP_GET_VARS['getVar'] you must now use $_GET['getVar']. There are other such similar SGAs.
Of course if you don't like this approach, you could always go back to the old way. A fuller explanation is provided on the PHP Website
Instead of accessing your server variables (ie GET,POST,COOKIE,SESSION,SERVER etc) variables directly, or by using the $HTTP_POST_VARS etc arrays, you will have to call them directly from their Super Global Arrays
PHP 4.1.0 introduced SGAs, which is a more secure way of accessing your variables to prevent hacking. Instead of access a 'GET' variable using $getVar or $HTTP_GET_VARS['getVar'] you must now use $_GET['getVar']. There are other such similar SGAs.
Of course if you don't like this approach, you could always go back to the old way. A fuller explanation is provided on the PHP Website
I just voted "I knew that allready", but this sticky post will most definitely help! because a LOT of people have trouble accesing their variables.
So leave it here for a while
:mrgreen:
Greetz Daan
So leave it here for a while

Greetz Daan
A quick fix to the register global problem, for each super global add the following lines of code
eg.
This will make all variables 'visible' again.. of course it also eliminates the extra security which is the reason for this chance in PHP.
eg.
Code: Select all
foreach($_GET as $key => $value){
$$key = $value;
}
This will make all variables 'visible' again.. of course it also eliminates the extra security which is the reason for this chance in PHP.
DutchBen wrote:A quick fix to the register global problem, for each super global add the following lines of code
eg.
Code: Select all
foreach($_GET as $key => $value){
$$key = $value;
}
This will make all variables 'visible' again.. of course it also eliminates the extra security which is the reason for this chance in PHP.
You would also have to do it in a very specific order to maintain the GPC relationship with the variables! I personally don't think it's a good idea, so I won't say what that order is ;)
I agree, its not pretty and destroys the whole purpose of the superglobals, but it can be a live saver.
Its supposed to be a fix to give you time to properly rewrite your code.
:roll:
This order you speak of... do you mean the EGPCS order? :wink:
Its supposed to be a fix to give you time to properly rewrite your code.
:roll:
This order you speak of... do you mean the EGPCS order? :wink:
DutchBen wrote:This order you speak of... do you mean the EGPCS order? :wink:
Yes, but most lay people refer to it as GPC, I believe that's what it shows up in the php.ini file as
Jay wrote:PHP 4.2.0 (and later) have disabled the register global settings by default, for enhanced security. What does this mean for you?
Could you explain what exact security enhancments this approach gives, please? I don't actually see any improvements. To my mind, script may be secured only with nice coding but not with putting some vars into array. Am I wrong?
An explenation on why to use the Global Arrays and why it is more secure can be found on this page on the php website
Greetz Daan
Greetz Daan
tsapen wrote:Jay wrote:PHP 4.2.0 (and later) have disabled the register global settings by default, for enhanced security. What does this mean for you?
Could you explain what exact security enhancments this approach gives, please? I don't actually see any improvements. To my mind, script may be secured only with nice coding but not with putting some vars into array. Am I wrong?
Well, just to give you an example, let's say you had a secure area of your website. You log people in via a cookie, and then you set a session variable that indicates they are logged in. So what's stopping someone from appending these variables in the url and setting the values like that? The answer is: NOTHING!
However, if you use the SGA, your script will be more secure. By using $_COOKIE['val'] instead of $val you instruct your script to take ONLY the value that's present in the cookie SGA, so anyone who tries page.php?val=var will not be able to get anywhere.
It's not just an array, it's arrays that a produced by PHP to separate all the variables out so you can ascertain exactly which one you want to use!
Jay wrote:Well, just to give you an example, let's say you had a secure area of your website. You log people in via a cookie, and then you set a session variable that indicates they are logged in. So what's stopping someone from appending these variables in the url and setting the values like that? The answer is: NOTHING!
I think variable initializing stops.
Also I don't think storing such vars in cookies is reasonable. You may store SID there but not "variable that indicates they are logged in".
You're missing the point. The idea is that the variables are clearly separated depending on where they came from. Let me give you another example
If my IP is 62.252.32.44 and I went to this url
http://www.yoursite.com/index.php?REMOT ... .252.47.68
What would the value of $REMOTE_ADDR be in your script? Will it be my true IP, or the fake one on the URL? It'll be the fake one (IIRC), which means anyone can get away with spoofing the variables.
If you use $_SERVER['REMOTE_ADDR'] (which PHP will set up automatically) then you'll know this is the true IP of the user and hasn't been manipulated or altered by them!
That's the idea. And BTW, I never said to store that they're logged in via a cookie. I said log them in via a cookie, and then set the session to store they're logged in (which is the same manner in which this, and many other sites work). This is the best method for enhanced security!
If my IP is 62.252.32.44 and I went to this url
http://www.yoursite.com/index.php?REMOT ... .252.47.68
What would the value of $REMOTE_ADDR be in your script? Will it be my true IP, or the fake one on the URL? It'll be the fake one (IIRC), which means anyone can get away with spoofing the variables.
If you use $_SERVER['REMOTE_ADDR'] (which PHP will set up automatically) then you'll know this is the true IP of the user and hasn't been manipulated or altered by them!
That's the idea. And BTW, I never said to store that they're logged in via a cookie. I said log them in via a cookie, and then set the session to store they're logged in (which is the same manner in which this, and many other sites work). This is the best method for enhanced security!
Thank you. I've got the idea.
But this is very strange that php does not redefine such vars with real values
But this is very strange that php does not redefine such vars with real values

tsapen wrote:Thank you. I've got the idea.
But this is very strange that php does not redefine such vars with real values
What do you mean?
Jay wrote:tsapen wrote:Thank you. I've got the idea.
But this is very strange that php does not redefine such vars with real values
What do you mean?
I mean that it would be better if PHP overwrite env vars like REMOTE_ADDR with their actual values.
That would be real security impovement :lol:
tsapen wrote:I mean that it would be better if PHP overwrite env vars like REMOTE_ADDR with their actual values.
That would be real security impovement :lol:
No need to overwrite them, the are seperated at the moment, wich in my opinion is even better.
That is, IF you're using the global array's.
The reason that GET, POST, COOKIE, etc variables are still declared as "normal" variables is for backwards compatibility for older scripts.
Also, you can set the order the normal variables are declared in your php.ini file, so that helps a little, but I still find it MUCH safer to use the global arrays.
Greetz Daan