vb.org Archive - Getting Ready for VB3

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

   ....

}

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.

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.

More info:

http://www.onlamp.com/pub/a/php/2003..._security.html

X vBulletin 3.8.12 by vBS Debug Information
Page Generation 0.01333 seconds Memory Usage 1,750KB Queries Executed 10 (?)
More Information
Template Usage: (1)ad_footer_end (1)ad_footer_start (1)ad_header_end (1)ad_header_logo (1)ad_navbar_below (3)bbcode_php_printable (2)bbcode_quote_printable (1)footer (1)gobutton (1)header (1)headinclude (6)option (1)pagenav (1)pagenav_curpage (1)pagenav_pagelink (1)post_thanks_navbar_search (1)printthread (10)printthreadbit (1)spacer_close (1)spacer_open Phrase Groups Available: global postbit showthread	Included Files: ./printthread.php ./global.php ./includes/init.php ./includes/class_core.php ./includes/config.php ./includes/functions.php ./includes/class_hook.php ./includes/modsystem_functions.php ./includes/class_bbcode_alt.php ./includes/class_bbcode.php ./includes/functions_bigthree.php Hooks Called: init_startup init_startup_session_setup_start init_startup_session_setup_complete cache_permissions fetch_threadinfo_query fetch_threadinfo fetch_foruminfo style_fetch cache_templates global_start parse_templates global_setup_complete printthread_start pagenav_page pagenav_complete bbcode_fetch_tags bbcode_create bbcode_parse_start bbcode_parse_complete_precache bbcode_parse_complete printthread_post printthread_complete
Messages: