[Security] PHP register_globals concerns

We have had a few more concerns regarding the register_globals issue. We talked about this in a previous post, which provided some good insight. However, we still have quite a few users that are requesting register_globals to be turned on and don’t understand why we can’t turn it on. This post aims to cover this in a bit more detail.

PHP’s register_globals can be a security risk. The keyword here is that it can be. In and of itself, register_globals is not an issue. Take someone who has a good strong programming background and register_globals doesn’t have to be an issue. Take that same person and ask them why register_globals should be left enabled, and you won’t get a reasonable response. If a programmer writes the code to their program correctly, then register_globals being on won’t be an issue. Any good programmer should know that securing their program is of the utmost importance. So the issue becomes, either a programmer spends more time securely defining their variables so that it can work in a register_globals enabled environment or they heed the advice of the entire PHP and PHP development community and code their script to work with register_globals off. A good programmer will recognize why having register_globals turned off and why writing a program in such a manner is a good thing.

The real issue here and to try and put this tactfully, is that PHP is a real easy language to learn. It is simple, yet powerful in creating dynamic websites. The end result is that there are a lot of PHP scripts out on the Internet that were written by programmers who had a lot less (if any) training than a seasoned programmer. These less trained programmers are not as adept at focusing on script security and input sanitation. I’m not saying that any of the PHP scripts I create are perfect in terms of security. I’m not saying that anyone can write a PHP script that is completely secure and will never have any security issues. I am just saying, if you had a project programmed, one by a 30 year programming veteran with 10 years of PHP coding versus someone that just wrote their first PHP program 2 months ago, whose program would you trust more?

The problem is there are a lot of PHP scripts available today are poorly written. They don’t take into account security of the script and they are not maintained or kept updated. They were just written one day by someone and forgotten about. This is where security issues pop up.

Ask anyone that has a website if they would prefer to have their website hosted on a server that is constantly blacklisted for sending spam or constantly being turned off due to phishing scams. They would all say no, everyone wants to be hosted on a reputable and secure hosting server. This is what we try to provide. If we relax our security procedures for even one account, then that relaxed setting can have ramifications for all of the webhosting accounts on that server. If by enabling register_globals for domain1.com on a server results in a hacker or malicious user breaking into that script and then using our server to send out spam, then we have effectively caused inconveniences for accounts, domain2.com, domain3.com, and domain4.com that are also hosted on this server. A server is not blacklisted based purely on the domain that was hacked into or exploited, when a server is blacklisted the entire server is blacklisted, regardless of what accounts are on that server or how the spam was sent out. Likewise a phishing scam on a server can result in connecting networks removing their connections to the server. Without network connectivity a webserver is as good as dead.

This is what users need to understand when raising concerns about register_globals being disabled on our servers. We as a webhosting company have to look after the well-being of all of our clients on the server. If we’re not, then we’re not doing our jobs. If we aren’t paying attention to basic security concerns, then we aren’t doing our jobs. For each account on a server that wants register_globals enabled there are atleast 100 other accounts on that same server that are grateful that we did not. If other webhosting companies are allowing register_globals to be turned on for any client requesting it, without offering to educate the client, then personally I would have to question that company’s dedication to offering a secure webhosting environment.

Check out the latest list of security vulnerabilities on Secunia which mention register_globals. At the time that I wrote this there were nearly 680 security vulnerabilities listed when you search for register_globals. I did not check all of these, but I suspect the vast majority of these include a line similar to “Successful exploitation of this vulnerability requires that register_globals is enabled.”

This is one of the best pieces of evidence as to why having register_globals disabled makes good sense in the webhosting community. There are new security vulnerabilities found in scripts everyday that require register_globals to be enabled in order to be successfully exploited. I don’t know when a particular script is going to be listed as vulnerable. Its entirely possible that there are scripts out there that are vulnerable right now and not listed with Secunia. Further, I don’t have any way of knowing specifically what scripts each account has installed. The safe bet is to disable register_globals. This way, whenever a new vulnerability comes out, if it states “Successful exploitation of this vulnerability requires that register_globals is enabled”, then with our servers having register_globals disabled, the vulnerability will have no affect on our servers.

To better understand how security can be circumvented in a register_globals enabled environment, I suggest reading a post from IBM’s website. Specifically read the section under the heading Unintended user input. This goes into a lot of detail as to how security can be circumvented in a poorly written PHP script. The author goes on to show that you can effectively reduce the risk of this behavior by defining your variables at the beginning of the script. This is probably not a bad idea itself, but if you are going to take the time to modify the script and define the variables at the beginning of the script, why not just go ahead and take the extra step and update the script to work with register_globals disabled? This is the part that I don’t understand. If register_globals is enabled, then chances are you are going to have to modify the script in order to define variables so that outside users cannot taint the variables. If you’re going to be modifying the script, why not just fix the script so that register_globals is not a requirement for the script.

The PHP language developers, the people behind the PHP language, recognize the security concerns with register_globals. They made the decision to remove register_globals completely in PHP version 6. Now PHP6 is a while away, but still, if you expect to use a script in a PHP6 environment, the script can’t require register_globals. So if you are having to modify the script, you might as well update the script to work better with future PHP releases.

This explains why having register_globals enabled on a webhosting server is a bad idea. Can a PHP script be written so that it is secure even with register_globals enabled? Yes, I won’t argue that point. The point I want to make is that I don’t believe that this happens very often. In order to really make this determination a script would have to go through a very extensive security audit. I don’t have the resources required to perform these individual script security audits. Even if a script was determined to be safe with register_globals enabled, this still doesn’t change the fact that PHP6 will deprecate register_globals completely. So even if your script is secure with register_globals enabled, you will have to modify the script again when PHP6 is released.

I just really cannot see a good reason to have register_globals enabled for a script. If a script is important to you, then you want that script to be secure. The best way to secure that script is to insure that it works with register_globals disabled. If you are running into an issue with a script that you downloaded or purchased, you should check to make sure that you are running the latest version of that script, as the issue with register_globals may have been taken care of with a script update.

I hope this helps explain the issues surrounding register_globals.

Scott Mutter

Director of Administration