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 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 also know that a PHP programmer has to start somewhere and you don’t learn until you make mistakes. I am just saying that if you had a project programmed by two different programmers, one by a 30 year programming veteran with 10 years of PHP coding, the other being someone that just wrote their first PHP program 2 months ago, whose programming skill would you trust more?
The problem is there are a lot of PHP scripts available today that 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. Relaxing your security procedures for even one account 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 account and then using your server to send out spam, then you have effectively caused inconveniences for accounts, domain2.com, domain3.com, and domain4.com that are also hosted on that 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.
End users and website designers need to understand this when raising concerns about register_globals being disabled on a web servers. A webhosting company has to look after the well-being of all of their clients on the server. For each account on a server that wants register_globals enabled there are countless other accounts on that same server that are grateful that register_globals is never enabled. It is my opinion that any webhosting company that blindly enables register_globals for any account that requests it, without considering user education about the issue, is not taking the well-being of the entire server into account. This brings into question what other security issues are they ignoring?
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. The vast majority of these include a line similar to “Successful exploitation of this vulnerability requires that register_globals is enabled.” This is basically saying that if your account does not have register_globals enabled, then you cannot be exploited by this vulnerability.
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. Nobody knows when a particular script is going to be listed as exploitable. There are scripts on the Internet that are exploitable that are not listed in Secunia or Bugtraq. In order to offer a broad protection against these exploits, register_globals should never be enabled.
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. PHP does not require that you define variables used in the script. It is good programming practice to know what variables you are using so that you can define them at the beginning, but because this is not required by PHP, it results in some of its insecurities. The majority of the PHP scripts available on the Internet do not perform any type of variable definition. However, if you are going to take the time to modify the script and define 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?
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. PHP 6 is likely several years away but still, if you expect to use a script in a PHP 6 environment, the script can’t require register_globals. So again, if the script is going to have to be modified to properly define variables, why not just go ahead and get the script ready for PHP 6 and recode the script to work with register_globals disabled?
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, but exactly how many PHP scripts are available on the Internet that are really secure? The popular scripts: Joomla, Mambo, WordPress, etc they were all rewritten years ago to work with register_globals disabled. The bulk of the scripts that are on the Internet today that still require register_globals are custom written PHP scripts written by PHP programmers who were less experienced or less experienced at the time they wrote the script. Do you really trust the security in those script?
I know a lot of the argument is “Well my script works now, why should I have to change?”. You just do. The straightforward answer is, if you are willing to police the entire Internet, then you can do whatever you want. Otherwise, if you want to be a part of the web community, then you have to uphold to the community’s standards. It’s the same reason why a high-priced luxury subdivision is not going to let someone build a shack on one of it’s lots. If you want to live in that community you have to be willing to accept that community’s rules. The same is true on the Internet. If you want to host a website on the Internet, you have to be willing to accept some of the Internet’s rules.
I just really cannot see a good reason why someone would want to have register_globals enabled for a script. If a script is important to you, then you want that script to be secure. With all of the scrutiny that register_globals has come under over the past several years, I would question the security of any script that still requires register_globals. Maybe the script is secure from a register_globals point of view, but what about other security issues? When was the last time the script was really reviewed by its developers in concerns with security?