Forum Moderators: coopster
I currently have an admin page which checks the username and password i enter (against an MD5 hash version of both). This obviously allows me to access all admin pages which check to see if the global variables username and password are set.
I was hoping someone might give me an idea as to any security issues that surround global variables, and whether i should use cookies for this purpose instead. Would it become an issue if I was to allow other people to register a username and password?
Any advice is appreciated!
Neil
I've actually never run PHP with register_globals on, so I've never paid attention to these issues that much. Way back when I was learning FORTRAN 77 (oh yeah) they had two commandments
- no globals if at all possible
- no GOTO statements
So I always keep them to a min and pretty much have always just used the built-in arrays. I've had second thoughts lately about using the superglobals in functions (bad for functional abstraction, but convenient).
Anyway, where auto-registered globals are a problem is that you must be careful not to accidentally overwrite variables.
So, for example, you have
if (is_admin($user_id))
{
session_register("is_admin");
}
On the next page, you let someone in based
if (!empty($is_admin))
and all they do is
[example.com...]
So if you aren't careful, you're giving away the keys to the kingdom. There are plenty of ways to lock down a script with globals on and pelnty of ways to leave it open with globals off. The main drawback to registering globals is that you have to keep so much more in your head and if you don't, you can introduce logic errors that are hard to track.
I don't want to have to remember, and it is very bad for data abstraction, if the form on the previous page has a field named "var" that's going to set a value for my variable named $var. So when I test
if (empty($var))
it says no because $var has the value from $_POST['var'].
I've had to run a few scripts with globals on and find it just aggravating to trace through the code.
While I'm ranting on the subject, I have similar feelings about setting an include path as in ini_set('include_path', 'path1;path2;path3'). I was playing with a script yesterday that had several different directories in the include path. I think this is terrible because
1. I need to remember that if the script is including a file from path2, I can't put any file with the same name in path1 or my whole script blows up.
2. When tracing through the script and bug tracking, I have to remember which path in the include path is the one that finds this. In the case of this script, the paths included PEAR (way outside of web root in the PHP dir), another path way outside of script root and, of course, the present working directory for the script. What a hassle.