View Full Version : Basic security question - URL tampering

08-05-2007, 09:45 PM
I'm slightly confused by some info I just read that was probably completely wrong, but I've become paranoid now, so I'm hoping someone will put my mind at rest with a simple yes/no answer to the following... :-)

If I have the code:

$_SESSION['logged_in'] = "no";
if ($logged_in == "yes") {
carry out something sensitive

and then someone appends to the URL:


there's no way that $logged_in could ever return "yes" unless I GET the variable, right?

I'm anticipating an "Of course, not!", but just wanna be sure I understand this correctly.


08-05-2007, 09:57 PM
In PHP 3 of earlier, it was possible like this. This was solved somewhere in PHP 4, as far as I know.

08-05-2007, 10:13 PM
This is (AFAIK) because of register_globals set to on. It's off by default in new php 4.x installations, and you can't turn it on (again, AFAIK) in php 5.x. The solution would be to either use
$_SESSION['logged_in'] = "no";
if ($_SESSION['logged_in'] == "yes") {
carry out something sensitive
or, what is simpler (especially if your using the variable more than once), creating the variable yourself:

$_SESSION['logged_in']$_SESSION['logged_in'] = "no";
$logged_in = $_SESSION['logged_in']
#created the variable yourself from the $_SESSION array
if ($logged_in == "yes") {
carry out something sensitive

08-05-2007, 10:56 PM
When register_globals are enabled, the parameter on the end of the url will cause the $logged_in variable in the program to be set to "yes", which is the whole security problem with register_globals.

The problem is only present on web servers where register_globals are enabled. You should specifically disable register_globals in php.ini (if this is your server) or a .htaccess file to avoid the possibility of variables having their value changeable from outside of your code.

Because the session variable shares the same name, it too will overwrite the $logged_in variable in some cases (just verified on my test server) -

Specifically, if the get parameter is not present on the url on the first visit to the page, the session variable will be created and the register global setting will cause the $logged_in variable to refer to the session variable with the same name. If you then refresh the page with the get parameter on the end of the url, the $logged_in variable will retain the value of the session variable.

However, if the get parameter is present on the url on the first visit to the page, the $logged_in variable will already have been created and refer to the $_GET variable with the same name and the session variable won't overwrite it on that page visit. If you then refresh the page, with or without the get parameter on the url, the $logged_in variable will again refer to the session variable with that same name.

Anyone trying this, don't forget to add a session_start() statement to the code in the first post to get the sessions to work.

Edit: Register_globals are not on by default in PHP5.x. Any documentation or statement to that effect is in error. The whole register_globals setting and any side effect from it have been removed in PHP6 - for security reasons and the problem of having different global variables ($_POST/$_GET/$_COOKIE/$_SESSION) being overwritten by other variables with the same name.

08-05-2007, 11:03 PM
Thanks guys,

So, given that I'm using php5, there's no problem, right? I don't need to take any other precautions (as Croatiankid suggested)?

08-05-2007, 11:07 PM
Check the actual setting for register_globals on your server. If it is a shared host, they likely turned it on to allow older scripts to continue to function.

08-05-2007, 11:27 PM
Blimey! I'm glad I asked again... shared host AAAARGH! That's what I've got.
OK, I'll check.

08-05-2007, 11:35 PM
Most decent web hosting services have register_globals disabled on shared hosting because of the security issue. A lot of them will not allow it to be turned on unless certain other criteria is met since enabling two or three other things that introduce security holes at the same time can compromise the entire server.

Fixing old (pre PHP 4.2) scripts to work with it disabled is trivial so any script that wasn't patched for this several years ago most likely has many other security holes in it as well if the authors can't be bothered to add the extra few lines of code needed to resolve that issue.

08-06-2007, 12:30 AM
I'm with HostGator, who, to my surprise, just confirmed that register globals are ON by default.

Does it make any difference if I turn it off with php.ini or htaccess?
Is one preferable for some reason?

If with htaccess, I just add:

php_flag register_globals off


(Incidentally, does it matter where in the htacces file I put it?)

08-06-2007, 12:39 AM
"Fixing old (pre PHP 4.2) scripts to work with it disabled is trivial".

I wouldn't make such generalisations. Some of the trickiest scripts to convert are ones that were written to work with register_globals off, but developed or modified on systems with it on.

So in order to catch the undeclared var, you have to load each script in all its modes of operation or have enormous powers of concentration while reading the scripts through. In the past I've come across 2 apps with register_globals holes and were a pain in the 455 to convert. These scripts had many vars whose values were get, post or session values depending on the mode of operation - php torture.