Can't access your variables?? Look here!!!

Did this sticky help?

  • Yes

    Votes: 0 0.0%
  • I knew that already

    Votes: 0 0.0%
  • No

    Votes: 0 0.0%

  • Total voters
    0
A

Anonymous

Guest
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
 
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
 
being new to an apache, php and mysql config/make, this actually helped me out with my code. I have some books that are a little bit older and didn't really address this issue.

thanks man....i'm off and running.

--
Happiness is a belt fed weapon.
 
A quick fix to the register global problem, for each super global add the following lines of code

eg.

Code:
 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 said:
A quick fix to the register global problem, for each super global add the following lines of code

eg.

Code:
 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:
 
DutchBen said:
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 said:
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?
 
tsapen said:
Jay said:
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 said:
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?REMOTE_ADDR=43.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 :?
 
tsapen said:
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 said:
tsapen said:
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 said:
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
 
Back
Top