My Site Script Broken in PHP5

 
<?php
     $ext = ".htm";
     $filename = $file . $ext;
     function file_exists_incpath ($filename)
     {
          $paths = explode(PATH_SEPARATOR, get_include_path());

          foreach ($paths as $path) 
          {
               // Formulate the absolute path
       	  $fullpath = $path . DIRECTORY_SEPARATOR . $filename;

        	  // Check it
        	  if (file_exists($fullpath)) 
  {
            	       return true;
        	  }
           }
           return false;
     }
if (!isset ($file))
{
     $number = "8";
     $category = "1";
     include("login/show_news.php");
}
else if(file_exists_incpath($filename) == true)
{
     include ("$filename");
}
else if(file_exists_incpath($filename) == false)
{
     echo("The page you have requested could not be loaded.");
}						
?>

I think my code is pretty straight forward.  It was working perfectly under PHP 4.7.7 but when I switched hosts and they started using PHP 5.2.2.  This broke my script.  Basically what happens is, the file_exist function keeps on returning false even though the file exists.  Also, the (!isset) function didn't work either.  Even with $file set it still shows the news page.  Am I missing something here to make it work in PHP 5?

Where is $file getting set from? If it is from a form or a url parameter, your problem is that the code is dependent on register globals being on and this has nothing to do with PHP version.

Where is $file getting set from? If it is from a form or a url parameter, your problem is that the code is dependent on register globals being on and this has nothing to do with PHP version.

Yeah $file is coming off of the URL.  I guess I'll ask my host if it is on.  But I'm pretty sure it would be on.  I switched back to 4.7.7 on my host and everything is working great.  But I just want to make sure it works on 5 to make it future proof.

Register globals are a huge security hole and have been eliminated in PHP6. Fix your code to work now with register globals off and it will keep working when PHP6 is released. Don't fix it now and it will stop working again on PHP6.

Register globals are a huge security hole and have been eliminated in PHP6. Fix your code to work now with register globals off and it will keep working when PHP6 is released. Don't fix it now and it will stop working again on PHP6.

Oh man.  So I best be re-writing my script instead?

To be honest, I have no idea where to start though.  Think you could give me a tip?

Basically what I want to do is the above.  Have my one index.php page call up a content file and paste it into the body.

while its a pain to fix its the better option

for example

add

$file = $_GET['file'];

to the start of THAT script should work

while its a pain to fix its the better option

for example

add

$file = $_GET['file'];

to the start of THAT script should work

Wow.  That one line fixed it for PHP5 for me.

So help me understand this lol That one line gets rid of having to use Register Globals?  This will work in PHP6 without a hitch? Am I still vulnerable to security holes that my script may have?

www.silenttweak.net is my site incase you think testing it would be better.  Oh and thanks for all your help guys! Can't believe how fast I got a response!

From the php manual -

When on, register_globals will inject your scripts with all sorts of variables

However, you do expect session variables to be safe from being set to a value by a hacker. There is an exploit present when register globals are on that allows an external value to be used in place of a value in a session variable. This does not actually set the session variable to a value, it sets the program variable with the session variable's name to a value, but you expect this program variable to be set from the session and not from a hacker putting a parameter on the end of the url. I just wrote this in a different thread in this forum -

What this means is if you are using session variables, which you would normally expect to be safe on the server and register globals are on and the code is referencing the session variable by its' registered global name $some_variable_name instead of $_SESSION['some_variable_name'], it is possible to visit a page, without visiting the page that sets that session variable first, and you can simply use a GET parameter on the end of the URL with the same name as the session variable and set that variable to any value you want in the code. For public scripts where the name of variables are known, this allowed things like making someone appear logged in or making them an administrator...

Basically, with register globals on, you don't necessarily know where a value in a variable came from (thank you register globals.)

Any $_POST['variable_name'], $_GET['variable_name'], $_FILES['variable_name'], $_COOKIE['variable_name'], or $_SESSION['variable_name'] variable that magically set's the program variable with the same name $variable_name needs to be changed to use the $_POST['variable_name'], $_GET['variable_name'], $_FILES['variable_name'], $_COOKIE['variable_name'], or $_SESSION['variable_name'] instead. This will both make sure that you know where the variable is coming from with register globals on and it will allow the code to work with register globals turned off (or when they are completely eliminated.)

There is a built-in php function that can extract() all the variables in an array and there are a number of php code snippets that "emulate" register globals being on that will blindly go through all the POST/GET/FILES/COOKIE/SESSION variables and populate regular program variables by the same name, however if these are not used carefully, they re-introduce the same security problems that register globals had.

It is best to individually go through and set program variables from the corresponding POST/GET/FILES/COOKIE/SESSION variable so that you only set the program variables that you know you want and you know where they got set from.

Am I still vulnerable to security holes that my script may have?