PHP Register Globals check may be inaccurate

What does phpinfo() say? Click on the blue php version number on Drupal's status report page for the phpinfo() details.
Does the entry for register_globals say Off in both columns? The Master value is the php.ini value, the Local value is from Drupal's .htaccess.

I am experiencing the same thing since installing 5.6. phpinfo tells me that register_globals is off for both local & master. However, Drupal continues to think that register_globals is enabled & outputs the above-mentioned error message.

I'm running:
PHP 5.2.5 & Apache 1.3

I think is depends on what directive is used in the Apache config files to set the register_globals flag. ie using php_value/php_admin_value register_globals with a value of 'off' instead of 0.
If you use 'off', ini_get() will return the string 'off' instead of 0. Refer to http://www.php.net/configuration.changes

Attached patch will cause anything else than '', 0, '0', or 'Off' to cause a register_globals requirement error. I've also moved the setting to it's own requirement so it will not mask PHP version errors.

Same problem here! 'register_globals' is off but Drupal 5.6 tells me that it is on. 'phpinfo()' says that it is off as it should be.

Neo X: If you have register_globals On, then you have a bug in your server configuration that is opening up security holes. The problem with not with Drupal. Set register_globals off in your .htaccess file (it should be already) or in your main server configuration.

If the admin for the server you're on refuses to let you disable register_globals, then you don't need to give up on Drupal. You do, however, desperately need to give up on the server because the admin is not doing his job and is giving you a server that is insecure by design.

@backlash: patch in #4 should solve that.

This issue is not about running Drupal with register globals ON.

It's about a wrong report on the status page / installer when register globals is OFF, but Drupal thinks its on.

It's a bug even.

Here's a version against 6.x

Slightly modified patch - uses php_register_globals so it's obvious that it's a PHP setting.

After some basic testing, this seems fine.

I'm having the same issue. I've checked in .htaccess file, and register_globals have a 0 value.

I've tried to check with phpinfo (link of php version on the Status Report Page) but I get:

"warning: phpinfo() has been disabled for security reasons in /home/user/public_html/modules/system/system.module on line 1779."

I've searched how to enable phpinfo, but I haven't found a way to do it. So I haven't been able to check through phpinfo if register_globals is enabled or not according to it.

Thanks,
Mguel

create a new file

add to it

// Show all information, defaults to INFO_ALL
phpinfo();

name the file phpinfo.php

upload it to your server
call the file in your browser

May also want to inspect your hosts admin panel as they may have a link to use to check phpinfo()

Hi, thanks for the reply.

When doing what you say and trying to open the file I get:

Warning: phpinfo() has been disabled for security reasons in /home/user/public_html/phpinfo.php on line 3

:(

if your host has stopped access to phpinfo() chances are high that they won't allow you to make alterations to default php settings. File a support request with your host.

OK, Thanks! I'll do that then.

The doubt I have is that I have register_globals to 0 in htaccess, so I'm not sure if I'm having the error of having register_globals on because of a drupal bug, or because it's enabled in php config.

Thanks again, Mguel

@the next poster.

I would like to keep some focus. Please think thrice to post a followup UNLESS you review / test the patch in #15, or have some insight to share.

Thanks in advance.

I've tested the patch in #15, under php 5.2.5 and 4.4.7 using as many combinations of setting register_globals (php.ini, httpd.conf, .htaccess) as I can think of. All tests report back as expected.

Two small issues with the patch
- not printing the register_globals value (patch in #14 did but it might have confused people)
- There is a number of unrelated code comment changes (please don't go and make other code changes other than what is directly related to the issue concerned)

Have the error on one drupal 5.6 site after the update. register_globals is off for the whole account (tested manually in several folders and via devel) The error doesn't accour on other sites on the same hosting account.

With the Patch of post #15 cygwin tells me "4 out of 6 hunks failed".
Result at /admin/logs/status: No change
With the Patch of post #4 cygwin doesn't print an error
Result at /admin/logs/status: Register globals Enabled (0 )

PHP Version is 5.2.5, Webserver: Apache/1.3.39 (Unix) mod_auth_pam/1.1.1 mod_fastcgi/2.4.6 mod_ssl/2.8.30 OpenSSL/0.9.8g mod_jk/1.2.25 FrontPage/5.0.2.2510

Better patch - checks for on, rather than !off, which seems to be easier to check correctly.

Attached patches for both D6 and D5.

If I add php_value register_globals 0 immediately below the module check/settings stuff for mod_php5 in the default htaccess-file, I get no errors. If I remove it or move it above the mod_php5 check, I get the register_globals warning - even though I am 110 % sure register_globals is off on my server. Weird.

Server:
Debian
Apache 1.3
PHP 5.x

Excerpt from .htaccess:

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

php_value register_globals 0

Please do not switch the version - the issue needs to be fixed in 6.x, then backported to 5.x.

Also, if you are testing - Please mention which, if any, patch you are trying.

@ wwwebernet, regarding the patches in #25; checking for Off or 0 was deliberate as I rather have the failure mode, where Drupal warns register globals being on when it isnt, then the inverse, where register globals is on but Drupal doesn't warn about it.

As we can only guess how PHP will interpret certain 'unknown' values, we need to be conservative and err on the side of caution.

As an example: your patch asserts that the string '1a' means that register_globals is not on, while in reality it is.

@orvad, we know of the bug, this issue deals with fixing it.

After further research, testing, and consultation with Heine, the attached patches use the same logic as #15.

The check isn't perfect and may result in false positives (the results returned by ini_get() can vary widely), but a least it shouldn't result in any false negatives.

Also - improved comments, and display the result of the ini_get() if register globals was determined to be on.

@pdelorme: This issue is not about changing the functionality with regards to register_globals. It is to address an issue regarding the proper detection of the register_globals value.

The change in functionality was changed due to a security advisory. See http://drupal.org/node/208565 for additional information.

Hello,

there's a solution which may also work in this case (it does for me, but it may also depend on the hosting environment: in this matter I don't know if it could differ). It consists in adding this line in the .htaccess file:
AddType x-mapp-php5 .php

(you can open the .htaccess file with a text editor like notepad++. In my case I just pasted it on the line 1 - at the beginning of the file -)

I found this solution in this blog's article:

http://www.nouvelle-aire.net/blog/index.php?2006/09/21/16-passer-le-regi...

I'm a beginner in Drupal and I'm not a php developer: so the reliability of this solution has to be confirmed by an experimented one. Anyway it worked for me.

Yours,

Michael

PS:

This command's line signifies that we want to use php version 5.0.

Yours,

Michael

I have deleted the off topic support requests from this issue. This code works well for me. ini_get sucks. However the comments need a little polish. Instead of false negatives / positives I would rather see an example or two.

Revised comments.

With register_globals_check-D5_1.patch

PHP register globals	Enabled ('0 ')
register_globals is enabled...

Notice the Space here: ('0 ')
Could this be the reason?

Can someone tell me exactly how to apply these patches to the system.install file? I see talk about applying these patches, but I don't know how.

@brian77nc: see http://drupal.org/patch/apply and http://drupal.org/patch

Please do not change the version.

Some IRC reviewing:

[9:35pm] goba: wwwebernet: the code comments in the globals issue are not consistent
[9:35pm] wwwebernet: goba: really?
[9:35pm] goba: it says "f the value is 'off', '', or 0" and "other than '' or 'off'"
[9:36pm] goba: 0 is not mentioned in the second list of values
[9:36pm] wwwebernet: goba: String other than ''
[9:37pm] wwwebernet: goba: Key word -- string.
[9:37pm] goba: wwwebernet: ini_get has this signature: string ini_get ( string $varname )
[9:37pm] goba: so then '0' is technically correct
[9:37pm] goba: and the "string other then" is not

Could install Drupal with the #25 Patch.
I understand why some might argue asking for globals the other way around is better.
Just wanted to let you know that it is working for me the one way and not the other at the moment.

Further comment improvements.

Instead of !empty($register_globals), can we use !empty(trim($register_globals))?

Yes, trim() is necessary. I was just bitten by this bug on a test site where ini_get() was returning '0 ' here (note the trailing space). :( Rerolled for both branches. Solves the problem on my site. Also, these patches don't include windoze linebreaks. ;) I didn't explain the trim() in the code comments, which otherwise look fine to my eyes now.

Hooray works for me now.
(Not tested with global_registers on so actually I can only say it recognises my global_registers off correctly now)

Looks like reviews are positive, so reviewed the code once more and committed to Drupal 6. Marking RTBC for Drupal 5.

Tested and committed to 5.x.

No matter what I try, the patch always fails.

I'm following the instructions but I just keep getting "hunk" "failed" errors.

drupal/modules/system > patch < patch_32.patch
(Stripping trailing CRs from patch.)
patching file system.install
Hunk #1 FAILED at 14.
Hunk #2 FAILED at 24.
Hunk #3 FAILED at 52.
Hunk #4 FAILED at 63.
Hunk #5 FAILED at 107.
Hunk #6 FAILED at 193.
6 out of 6 hunks FAILED -- saving rejects to file system.install.rej

That's probably because the patch is already included in 5.x-dev and 6.x-dev.

drumm committed the patch in #52.

So, when your patching program scans for the text in the patch to be replaced, it doesn't find it (since the new text is already there), giving you failed hunks.

Since the patch has been applied, you can download a copy of 5.x-dev, which will contain the modifications in the patch automatically.

Okay. I guess I don't understand why the installation isn't picking up on the "register_globals = 0" in the .htaccess file.

Actually, I think I'm okay.

I did some more google searching and found an item on someone's blog that suggested adding this line to the .htaccess file:

AddType x-mapp-php5 .php

It appears to be working.

It does work.
Combination of setting globals to 'Off' in .htaccess file and adding "AddType x-mapp-php5 .php" allows to continue installation of the Drupal 5.6

K sorry this worked on my 6.0rc3 install but i think i had to do something similar for 5.x. I have PHP5 on Bluehost, and adding this string to the standard .htaccess (below the mod_php5 part) worked to get past the register_globals objection, in fact it actually changed the status of register_globals itself:

AddHandler application/x-httpd-php5 .php

Now... I can install 6.0rc3. and report it on the wrong thread :)

Installing 5.7. I didn't apply a patch yet because I was trying some of the quick .htaccess modifications suggested above. None of them worked except the suggestion in #59 (thanks HongPong). No problems afterwards.

Host is Host Gator running PHP version 5.2.2.

A further update about register_globals, Bluehost, Drupal 6.0RC3 and the warnings about register_globals being on:

Platform: Linux boxXXX.bluehost.com 2.6.22-9_1.BHsmp #1 SMP Fri Sep 28 23:36:16 MDT 2007 x86_64
Server API: CGI/FastCGI
Configuration File (php.ini) Path: /usr/lib
Loaded Configuration File: /home/**user_dir***/public_html/php.ini
PHP Version: 5.2.5

I tried the solution above (AddHandler application/x-httpd-php5 .php) but a phpinfo(); kept returning "On"
I also modified the .htaccess file but no luck.

In the process I stumbled upon

http://it.php.net/manual/en/ini.core.php#ini.register-globals

Which states to use

php_flag register_globals off

Even then, it kept ignoring the directives.

In the end I had to open the "Loaded Configuration File" indicated php.ini file and manually set the directive off in there.

Immediately after this operation, phpinfo(); returned Off, and the Drupal warning stopped being issued.

Not sure how this can help Drupal, but those using Bluehost now know to double check their installation.

This issue is about an inaccurate check by Drupal for the register_globals setting.

To get support on changing your server settings, please open a forum thread.

Try fixing this by adding the file php.ini to the root folder in the webserver
with this statement

register_globals=off

This will customize your web folders php settings.

how would be the patch for drupal 5.7?

Drupal 5.7+ and Drupal 6 RC3+ include the changes in this issue.

Please open a new issue for any additional problems with the register globals check.

Trying to install 5.7 and not able to get around the register globals issue.

In my case the globals is ON for our server because some of the older php apps need it.
I have my drupal install in a subdirectory off the root: /home/smith/smithcms

I tried putting a modified php.ini in the /smithcms directory but no luck.

Can I make this work?

Hi,

in the last 3 years I've built over 50 Drupal sites (admittedly on older versions), none of the installs for which took longer than 30 minutes. I have now today spent 4 hours trying to get the latest 6.2 to work, with exactly the problem as outlined here (register_globals is enabled. Drupal requires this configuration directive to be disabled. Your site may not be secure when register_globals is enabled. The PHP manual has instructions for how to change configuration settings. (Currently using PHP register globals Enabled ('1')))

I have tried all the solutions outlined here apart from the patches, which fail (I guess they don't apply to the latest 6.2). Having root on the server, I've also modded php.ini and spliced .htaccess into a directive in the global httpd.conf. None of this works.

I have probably missed something somewhere, but right now I am very frustrated and wishing to hell I was using something else. Any help gratefully received.

Matt

This issue is about an inaccurate check by Drupal for the register_globals setting.

To get support on changing your server settings, please open a forum thread.