Re: PHP and "Register_Globals"

From: Jim McGarvey <jim.mcgarvey(at)interblink.com>
Date: Sat Mar 29 2003 - 17:52:57 EST

> > my question is now: my app is 'safe', but what do I do if my future

If you have to have a quick fix, the suggestion of having your provider make a change to your VirtualHost setting in Apache will work, though some providers will not or cannot do that. If that's the case you can try creating a .htaccess file in the directory where the application is and putting that line, "php_value register_globals on" in the .htaccess file. This will only work if your Apache VirtualHost entry already has a "AllowOverride All" or "AllowOverride Options" in it, which is pretty common.

There are other solutions at the following URL, though I haven't tested any of them:
http://www.php.net/manual/en/security.registerglobals.php

But since this list is about security, I would be remiss if I did not mention the drawbacks of such a quick fix. You did not provide any us with any evidence that your app is really 'safe' other than your assurance that it is. Just remember that we all make mistakes, and it's possible that you have missed something, or that you will make a quick change in the future that misses something, or more likely that someone else in the future will need to maintain your application and they will introduce a vulnerability.

I strongly suggest you do something like Adrian suggested for each variable in each php script that needs any form or cookie variables:

---

if(isset($_REQUEST['varname'])) $varname=$_REQUEST['varname']; else $varname='defalut_value';

---

or maybe create a helper function that does the same thing but is a little more readable, since you probably don't have default values:

---

$varname = getRequestVar('varname');

---

It's a simple matter of declaring which inputs you are expecting at the top of every php script that uses cookies or gets form variables passed to it. I think it also helps with code readability and maintainability, because when you look at the script, you know right away what data is coming from the user. That also makes validation easier, because you know exactly what variables in your script you need to validate, so its easy to see whether or not you have actually done all the validation that is necessary.

> > I soon realized the security issues, and wrote my own
> > validation-functions, ... to handle all the XSS and SQL-injection
> > problems.

I'm sure you already know this, but just to be clear, the register_globals security issue isn't usually a SQL-injection problem, and validating variables that you are expecting from user input isn't the problem. The problem is when a user passes a form variable that you are not expecting, and the name of the form variable they pass corresponds to the name of one of your internal variables. Here is an example of vulnerable code:

// validate html variables to ensure not SQL-injection attack $username = removeNonAlphaNumeric($username); $password = removeNonAlphaNumeric($password);

// check if a valid username and password were supplied if (checkPassword($username,$password) {

    $good_login = 1;
}

// is supposed to only allow users with valid username and password if ($good_login == 1) { // can be forged by a user in get/post/cookies,

    fpassthru ("/highly/sensitive/data/index.html"); }

someone can bypass this by accessing the script like this: site.com/go.php?username=madeup&password=bogus&good_login=1

So not only is it necessary to validate the html/form variables to be safe when register_globals is on, it's also necessary to initialize or validate every internal variable in every script, every class, and every function, such as the $good_login variable above.

I just think it's easier and safer to spend the time going through your code and declaring the cookies and form variables you are expecting as input rather than making sure every internal variable gets initialized. But that's just my opinion and how I like to do it. And not having to convince your provider to make customizations for your site is a plus.

-Jim

• Original Message ----- From: "shimi" <shimi@shimi.net> To: "Ulrich P." <spam@wir-sind.org> Cc: <webappsec@securityfocus.com> Sent: Saturday, March 29, 2003 10:40 AM Subject: Re: PHP and "Register_Globals"

>
> just ask your provider to add the following in your VirtualHost:
>
> php_value register_globals on
>
> and this will be enable for your site, and your site only...
>
> alternatively, you can use a function that does just that (imports
> everything automatically). see:
> 
http://www.php.net/import-request-variables
>
> good luck.
>
> On Sat, 29 Mar 2003, Ulrich P. wrote:
>

> > hello,

> >

> > newer php-versions have set "register_globals" to "off" by default. i
> > programmed a huge php-project during the last year and didn't start
> > using the global POST and GET-arrays, so if a form contains <input
> > type=text name=age> if use $age in my scripts.

> >

> > I soon realized the security issues, and wrote my own
problems.

> >

> > my question is now: my app is 'safe', but what do I do if my future

> >

> > would it be possible to write a script that registers the whole
> > POST-array as single variables? simply as it used to be in 'older'
> > PHP-versions?

> >

> > any ideas welcome :)

> >
> >

> > regards,

> >

> > Ulrich

> >
>
> --
>
>   Best regards,
>      Shimi
>
>
> ----
>
>    "Outlook is a massive flaming horrid blatant security violation, which
>     also happens to be a mail reader."
>
>    "Sure UNIX is user friendly; it's just picky about who its friends

are."

>
>
>

Received on Sat Mar 29 18:05:41 2003