Getting Ready for VB3 - A Coding Tutorial

[amykhar]

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 (http://hotwired.lycos.com/webmonkey/01/48/index2a.html?tw=programming) 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 (http://www.google.com/) 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:


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:


if ($userid == 1) {
// this is the admin id, let the person do what they want
....
}


It would be trivial for somebody to construct a url such as http://www.stupidscript.com/secure.php?userid=1

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.


$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.

More info:

http://www.onlamp.com/pub/a/php/2003/03/20/php_security.html

[Gary King]

Nice post you made here amy :)

I always code with register_globals set to OFF, because, as you quoted, it is quite insecure, and the default is now set to off (although many webhosts still set it to ON for the convenience of its customers).

[Erwin]

Nice tips. :)

[amykhar]

Thank you :)

[GCPrez]

06-27-03 at 02:43 PM Gary W said this in Post #2 (https://vborg.vbsupport.ru/showthread.php?postid=413440#post413440)
Nice post you made here amy :)

I always code with register_globals set to OFF, because, as you quoted, it is quite insecure, and the default is now set to off (although many webhosts still set it to ON for the convenience of its customers).


Please explain to me why it's convienient for people that install scripts and don't know much about coding? Aren't most scripts assuming register glabals are turned off? I just don't understand how it's a convienence if it's a security hole.

[NTLDR]

Its convenient because variables are global as the name sugests. For example it may be posible to overwrite a value by appending it to the URL:

EG: URL: test.php?debug=1


if ($debug)
// do stuff
}


In the above example it checks if $debug is set, if there has been no declaration within the file and register_globals is ON then it will take the variable value from the URL, which may not be desired. If register_globals is OFF then you would need to use $_REQUEST['debug'] or $_GET['debug'] to access that variable within the script.

vB2 works with register_globals ON or OFF and registers the globals for you if its set to OFF. Its convenient because many scripts still require register_globals set to ON, hence why many hosts have it turned on.

[GCPrez]

Thanks Lee! I understand that now. :banana:

[ap0c]

great thread, any more pointers on the way?

[kill_emma]

o_< reminds me of "Getting Ready for Y2K"

[gmarik]

Has anybody read my tips?
If not, can add them here.

[KuraFire]

<snip>

$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 :)


EG: URL: test.php?debug=1


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:

isset($variable)

if you want to know if the variable evaluates to TRUE, use:

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 :))