My husband is a Visual Basic programmer (ick) and he?s always after me to teach him web development. So, when I started working on a redesign of a modification for VBulletin 3, I told him that he could help me code it. To get him started, I installed a local version of PHP on his computer, and sent him to Web Monkey to take a tutorial.
Shortly after he got started, he yelled for help. He was working on reading data from a form and printing it out to the screen and the data refused to print. I read the code several times, and everything seemed correct. After a couple of minutes of tinkering, I saw that data within his PHP script would print, but not the data being passed in from the form.
Suddenly, in the deep recesses of my mind, a tiny lightbulb went on in my head, and I went to Google to research Register Globals.
By default, Register Globals is now set to OFF in PHP versions 4.2.0. In previous versions, it defaulted to ON. Therefore, things that we always assumed were just how PHP worked (such as being able to process form data easily) work a bit differently now.
The official PHP documentation says:
Quote:
When on, register_globals will inject (poison) your scripts will all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier. It was a difficult decision, but the PHP community decided to disable this directive by default. When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this.
To solve my husband?s problem, I quickly went to his php.ini file, turned Register Globals on, and restarted Apache. Problem solved - the lazy way.
What I really should have done was teach him how to code properly when Register Globals is off, and that is the point of this tutorial. Vbulletin 3 is coded to work with Register Globals off, and any modifications we write should be as well.
So, it?s time for us to break some bad habits and learn how to write elegant, more secure code.
One of the blessings, and curses, of PHP is that it?s easy and it forgives mistakes. Unlike other languages, PHP does not require us to initialize variables. This makes it cake to throw together a script or VBulletin modification in a matter of minutes.
Unfortunately, the ability to code quickly and easily makes it just as easy to code sloppily. Just about all of us have been guilty of sloppy coding at one time or another. It?s too easy to just throw together something that works and forget about form and style.
Sloppy coding can create security holes though.
Take this example:
PHP Code:
if ($userid == 1) {
// this is the admin id, let the person do what they want
....
}
and whether they were an admin or not, they could possibly do some pretty naughty things.
By initializing userid to something else, and by validating incoming data, we could prevent havoc and mayhem.
PHP Code:
$userid = $_COOKIE['userid]; // initialize userid so that it contains a value from a cookie and only from a cookie
if ($userid == 1) {
// this is the admin id, let the person do what they want
....
}
The code above isn?t totally secure. It won?t let a prankster set the userid in a GET or a POST request, but the cookie could still be forged. Data needs to be validated in several ways if security is a concern.
With Register Globals set to OFF, form data is retrieved by using the following syntax:
$variable1 = $_POST['variable1'];
or
$variable1 = $_GET['variable1'];
Whether you use $_POST or $_GET depends on the type of form used.
Even if security isn?t an issue, having Register Globals set to off can help stop bugs from creeping in.
In VBulletin 2.x, it was possible to break the functionality of the board by using the wrong variable name in the phpinclude template. With Register Globals set to off, such problems might be prevented because variables will have to be intentionally passed into a script and won?t just drift in on their own.
Having Register Globals set to off won?t cure the world?s ills, and it will take some time to learn. But, if you are going to release code modifications for VBulletin 3, you should master the concept and use it.
$userid = $_COOKIE['userid]; // initialize userid so that it contains a value from a cookie and only from a cookie if ($userid == 1) { // this is the admin id, let the person do what they want .... }
<snip>
You have a little parse error in your code:
$_COOKIE['userid]; will give a parse error, it should be:
$_COOKIE['userid'];
Just FYI that you typo'd
Quote:
Originally Posted by NTLDR
EG: URL: test.php?debug=1
PHP Code:
if ($debug) // do stuff }
In the above example it checks if $debug is set, ...
Actually, to be entirely precise, it checks whether the variable $debug evaluates to TRUE.
There is a vital difference between a variable that is set and a variable that evaluates to true.
This is important to note, because for starting programmers it's important to know the difference
For instance, if I SET my variable like this:
$debug = 0;
the variable is set fine, and it does exist fine. But it won't evaluate to TRUE, and so that if () will not occur.
If at any point you want to know if a variable is SET, use:
PHP Code:
isset($variable)
if you want to know if the variable evaluates to TRUE, use:
PHP Code:
if ($variable)
etc....
(for detailed hacking guidelines, wait a while until vB3 RC1 is out and we have the Hacking Document ready at vB.org )
06-26-2003, 10:00 PM
10-30-2003, 02:32 PM
