The risks of Register Globals

Dev

The risks of Register Globals

by Sean Corrales

If you’re listed as the technical contact for your company’s website, there’s a good chance that you’ll receive a letter from your hosting company announcing that they will be turning off “register_globals”. If you’ve googled register_globals, you probably found a lot of articles detailing the risks but no real explanation of whether your site is affected or if you need to take any action.

Should I worry?

Yes, you most definitely should. It’s not a question of “if” your web host will shut off register_globals but “when”. Many developers learned to develop PHP applications relying heavily on register_globals before the security risks were well known. If you’ve had a PHP based website or application developed over 3 years ago, there’s a higher chance that your site may depend on register_globals. Even if your host hasn’t turned off register_globals yet, your site is still at risk to malicious users.

How can I find out if my site is at risk?

The easiest way is to contact your web host and ask them if register_globals is turned on and if you’re running any PHP scripts. This, however, doesn’t cover all your bases. Developers can turn register_globals on in single directories using htaccess overrides. As web hosts attempt to shore up their security, these directory overrides will stop working, as well. The safest way to go is to have a site audit conducted on all your PHP scripts. This is the only way to truly be certain your site is not vulnerable to register_globals related issues.

What should I do if my site is at risk?

If you haven’t already conducted a site audit, now is the time to do it. A developer will then go through the site to check your scripts to make sure they do not rely on the register_globals functionality. If your site does rely on this functionality, the developer will need to go back and fix these sections of your site to no longer rely on register_globals. Once a developer has done this, your site will be more secure and ready for future upgrades to PHP.

If, in the past, you’ve encountered issues where register_globals had been turned off and a developer fixed the issue for you, it’s worth reviewing that developer’s work. Oftentimes, developers would take short cuts and re-enable register_globals within certain directories. This temporary fix may have been quick and saved you a few bucks but when register_globals is disabled for good, those issues will come back to haunt you.

More About the Author

Sean Corrales

Lead Web Developer
Internet Explorer ignoring CSS files Like most web developers, I do most of my development work in one browser (in my case, Firefox) and then do cross browser checks after ...
Creating checkout panes for Ubercart All code comes from a shipping insurance module I wrote for Ubercart. I plan to release it on ubercart.org and drupal.org after I ...

See more from this author →

Subscribe to our newsletter

  • I understand that InterWorks will use the data provided for the purpose of communication and the administration my request. InterWorks will never disclose or sell any personal data except where required to do so by law. Finally, I understand that future communications related topics and events may be sent from InterWorks, but I can opt-out at any time.
  • This field is for validation purposes and should be left unchanged.

InterWorks uses cookies to allow us to better understand how the site is used. By continuing to use this site, you consent to this policy. Review Policy OK

×

Interworks GmbH
Ratinger Straße 9
40213 Düsseldorf
Germany
Geschäftsführer: Mel Stephenson

Kontaktaufnahme: markus@interworks.eu
Telefon: +49 (0)211 5408 5301

Amtsgericht Düsseldorf HRB 79752
UstldNr: DE 313 353 072