Re: PHP and "Register_Globals"

["Ulrich P." <spam () wir-sind org>]

hello group,

thanks for all your extensive feedback! there are some quite 'nice' 
solutions to work around this problem.

I am aware of the security issuses, but my problems are:

- the application started being developed *before* the register_globals 
discussion was started
- the application is *huge*
- no one will pay me for re-writing tons of code :o(

fortunately I did the login-things in the end of the project, so that I 
used all the new features for the login-procedure and also for the 
'good_login'-problem.

without logging in you can't do anything in this app. that's the good 
thing. and the logged in ones are 'only' staff members of the company I 
wrote this for. so *possibly* no real cracker, but a secretary *g*.

do you still think that I should re-write?

the issue is not that I am 'lazy' but that no one will understand the 
problem and pay for a fix up. and I have to feed my dog ;-)
BUT: of course I don't have a very good feeling about all this if it's 
kept as it is.


thanks again for your ideas and
best regards,

Ulrich




Jim McGarvey schrieb:
> > > my question is now: my app is 'safe', but what do I do if my future
> > > webhost has register_globals to 'off'?
>
>
> 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
> > > validation-functions, ... to handle all the XSS and SQL-injection
>
> problems.
>
> > > my question is now: my app is 'safe', but what do I do if my future
> > > webhost has register_globals to 'off'?
> > >
> > > 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."
>
> >
>
>
> .