vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vBulletin 3 Articles (https://vborg.vbsupport.ru/forumdisplay.php?f=187)
-   -   Getting Ready for VB3 - A Coding Tutorial (https://vborg.vbsupport.ru/showthread.php?t=54815)

amykhar 06-26-2003 10:00 PM

Getting Ready for VB3 - A Coding Tutorial
 
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

Gary King 06-27-2003 05:43 PM

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 06-28-2003 02:03 AM

Nice tips. :)

amykhar 06-28-2003 02:25 AM

Thank you :)

GCPrez 08-20-2003 01:16 PM

Quote:

06-27-03 at 02:43 PM Gary W said this in Post #2
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 08-20-2003 04:52 PM

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

PHP Code:

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 08-20-2003 06:06 PM

Thanks Lee! I understand that now. :banana:

ap0c 08-20-2003 09:29 PM

great thread, any more pointers on the way?

kill_emma 10-05-2003 07:04 PM

o_< reminds me of "Getting Ready for Y2K"

gmarik 10-30-2003 12:38 PM

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

KuraFire 10-30-2003 02:32 PM

Quote:

Originally Posted by amykhar
<snip>
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
    ....
 } 

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


All times are GMT. The time now is 04:31 AM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01238 seconds
  • Memory Usage 1,769KB
  • 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
  • (7)bbcode_php_printable
  • (4)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (11)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
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete