Hosting company advised us to avoid PHP for security reasons. Are they right?

Question

I'm doing a redesign for a client who's understandably concerned about security after having been hacked in the past. I had initially suggested using a simple PHP include for header and footer templates and a contact form they wanted. They are reluctant because they were advised by their hosting company that using PHP is a security concern which might allow someone to break into cPanel and gain control of the site.

This, to me, sounds about like telling someone to never drive so they won't be in a car accident. My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system. Also, the server still has PHP installed, whether or not we use it, so I'm questioning how much this actually reduces the attack surface... But since I'm not a security expert, I don't want to stick my foot in my mouth.

I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?) They asked if I could just use PHP on that one page. Would this be measurably safer, or is it the equivalent of locking your car doors and leaving the window rolled down?

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem? We're on shared hosting with no SSL. Is it reasonable to assume we got hacked due to using PHP? Will we be any safer if we don't use it, but can't uninstall it? Because if not, we have other problems.

(Would the answer be different for any other language?)

Answer 1

It's not so much that PHP itself has security problems (assuming needed security updates), as it is there exists a lot of popular PHP-based software with rampant security problems. You could fault PHP for being a language that gives you enough rope to choke yourself, but the real problem is just how prevalent vulnerable PHP code actually is. One need look no further than the Stack Overflow PHP tag to find PHP newbies writing horrifically vulnerable code based on some atrocity of an old tutorial.

Additionally, a significant number of popular PHP software known for their rampant security flaws is based on very old code and coding practices. Many of these old practices are considered bad-practices because of inherent security problems.

This, to me, sounds about like telling someone to never drive so they won't be in a car accident.

Pretty much yes. Better advice might be along the lines of "don't drive an old car with no airbags".

My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system.

Not necessarily. If a user uses the same password for the WordPress site and cPanel, compromising the WordPress password also compromises cPanel. That would be the fault of the user. Hackers rarely need to get that far though, and just use a PHP shell.

I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?)

Not necessarily true. You could use a 3rd party service to handle the mail sending. Then the service handles the dynamic server scripting and take over the security implications. There are numerous such services available with varying feature sets, and they are popular for powering contact forms on statically generated sites.

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Some, but not much. PHP does involve some active code, in both PHP and the server software which executes it. If there were ever a security vulnerability in that process which did not depend on specific PHP code, it could be exploited. While that risk is tiny, it's a risk a server with no such support does not have.

Answer 2

"Right" might not be the right word, but "wise," "prudent" and "conscientious" come to mind. PHP has, since its inception, adhered to a philosophy that devalues correctness in software. There is a huge number of situations a program can encounter where other languages (e.g. Python) would give up and throw an error to tell you that your program is wrong, but PHP instead chooses to do something nonsensical and carry on as if things were just fine.

Keep in mind that correctness is very important to security. A language that is prone to silently ignoring errors left and right will have more than its fair share of programs with security problems. For example, you may have a piece of code that your programmers think is protecting against a certain attack, but in fact is being skipped because the interpreter ignores an error.

In addition:

• PHP is designed to appeal to the lowest denominator of programmers with the least motivation to get good at their craft. And thus the most likely to write insecure software.
• The PHP team has a history of profoundly flawed attempts at fixing common security problems. Look for example at SQL injection protection, which betrays repeated flawed attempts at fixing the problem: real_escape_string (because the original escape_string was broken, but they didn't remove it until later) vs. addslashes vs. mysql_escape_string/pg_escape_string and so on. Whereas pretty much every other language just went with prepared statements and query parameters and got a design extensible to all databases right on the first try.

So for all the talk in other answers about how you can write secure software in PHP, if you try it you're very much swimming against the current.

Answer 3

PHP's security problems can generally be narrowed down to two categories

Unpatched systems

As of right now, Wordpress stats shows over half of all users are running PHP on versions of PHP that are past End of Life (PHP 5.2 - 5.4). In two weeks, PHP 5.5 goes EOL and then it jumps to about 80% of all installs. Now, to be fair, some Enterprise/LTS Linux installs will backport security fixes, but the vast majority of them are not using backported fixes (or some don't patch their systems). Worse, lots of people refuse to upgrade PHP itself. Either they can't/won't update their code, or they think that older software is more stable.

Wordpress (#1 PHP application used worldwide) made a concerted effort to make sure users stay up to date on the software itself (and they've made great strides), but despite that, only 40% are running the latest version of Wordpress. That means some 60% may have an unpatched security vulnerability. And that's just the base program. Wordpress has a massive ecosystem of plugins, and many of them have security vulnerabilities of their own.

Then there's other issues, like lots of older code using the defunct mcrypt library. And that's just one PHP plugin you can compile.

Now extrapolate this to the servers not running and reporting stats to WP. It doesn't paint a pretty picture. Last summer I found a website running an e-commerce page that was still on Apache 1.3.3 and PHP 4.1.2. It was so old it had SSLv2 enabled...

Bad Practices

If you hang around SO PHP questions long enough, you'll see a lot of people practicing bad code. Some of the problems I've seen over the years

• SQL Injection
• Thinking MD5 is a good way to protect passwords
• Using outdated APIs int their code (i.e. ext/mysql, the old MySQL connector)
• Trusting user input to execute code (i.e. using eval with user supplied data)
• Not turning off security risks in the PHP code (i.e. the exec function)

To the untrained, this looks like a PHP problem, when it's the coders and their ecosystems that produce the problems. Maybe they were in a hurry. Maybe they hired some guy who does this in his spare time and "just made it work".

Can it be secure?

YES! But that security requires some effort. Keep your PHP install up to date. Heck, keep your whole server up to date. Host won't do security and patches? Find another host. (I'm amazed at the people who balk at this). Build your own server (VMs are cheap). But above all, pay attention. Learn all you can about security. Don't just let your website and server go out to sea.

Someone who tells you PHP is insecure is just being lazy.

Answer 4

PHP is no less, or more secure, or insecure than any other language (Java, Rails, etc). It is all about the coding. Are checks and balances in place to deflect, defend, prevent, and or mitigate an attack. Quoting:

WhiteHat Security performed vulnerability assessments of more than 30,000 websites using .NET, Java, ASP, PHP, Cold Fusion and Perl. The most widely used languages were .NET (28.1 percent of Web applications), Java (24.9 percent) and ASP (15.9 percent).

...

The programming language .Net had an average of 11.36 vulnerabilities per slot, Java 11.32 and ASP 10.98. The most secure language, ColdFusion, had six vulnerabilities per slot. Perl had seven vulnerabilities per slot and PHP had 10.

...

Java accounted for 28 percent of vulnerabilities found and ASP 15 percent. “Again, the number of applications written in the language along with the complexities of the websites has to be considered as a contributing factor,” said the report. PHP also accounted for 15 percent of vulnerabilities discovered. ColdFusion only accounted for 4 percent of vulnerabilities and Perl 2 percent. (source)

This says nothing about how sites were developed in terms of good coding practices. For example, if you took unskilled (for lack of better terms) programmers in each language, these numbers could be reversed and perl could have the most vulnerabilities, with .Net having the least. It all boils down to what the code itself is supposed to do. Has the code been programmed to perform its sole function with tampering/abuse tested before it was put into development?

There are plenty of security cheat sheets, best practice guides, and other write-ups that cover security issues but this becomes a situation where the client is weary based on the advice from their provider. This is can be a hurdle since it becomes a "he said" she said sort of struggle to convince your client to allow you to create the site using PHP. A method I might use if I still wanted to use PHP would be to create a demo site, then use a vulnerability assessment scanner (Acunetix, AppScan, Burpsuite) against it to check for flaws. If none are found I would present the report detailing the security posture of what you have built to both the client, and create in such a fashion (PDF, etc) that it is presentable to the provider.

Answer 5

One of the fundamental problems with PHP is really a fundamental problem with the CGI model of things (upon which PHP is based, despite mod_php's trappings) - namely that user-facing data is intermingled with scripts, and it becomes very easy for e.g. user uploads to become an executable script. This isn't necessarily a problem with PHP itself but having PHP available on a system at all makes it a very large attack surface; quite a few WordPress plugins' security issues come from this aspect of it, for example.

Traditional CGI-based deployments historically mitigated this issue by only allowing CGI scripts to run from a trusted directory (such as /cgi-bin/) but many shared-hosting providers eventually relaxed this restriction for "convenience," and that same convenience is pervasive throughout PHP.

Many modern PHP-based applications often use .htaccess as a quick-and-dirty request-routing mechanism which does help to mitigate these problems, but this is far from universal and still isn't an easy cure.

In my opinion, the biggest problem with PHP is just that it's so easy for arbitrary PHP code to be made available to execute on any server where it's configured, and thus while code written in PHP isn't necessarily more or less secure than code written in other languages (although its standard library doesn't exactly do any favors when it comes to writing secure code), the mechanism by which PHP scripts execute provides a massive security challenge by merit of PHP even being available on a server.

Answer 6

I agree with your assessment that using PHP does not necessitate a security risk. There are some vendors that shy away from PHP for much the same reason that WordPress is viewed as a security risk. It's popular. The more prevalent something is, the more energy gets invested into developing exploits.

That said, I wouldn't avoid PHP if it's implemented properly, receives timely patches, and has some level of monitoring to detect malicious activity. Bottom line: security risks are security risks agnostic of the platform. Changing scripting languages does not mitigate the security risks associated with poorly written / developed / implemented code.

Answer 7

If all you want is to include a standard header/footer, PHP might be overkill - simple server-side includes could do that.

PHP is not inherently dangerous, as previous answers have argued. But if you don't need a full scripting language on the server, then best security practice is not to install one. If as you say PHP is going to be installed on the server anyway, then the additional risk created by using it is about zero as long as you don't do anything stupid. And including a template is not stupid unless you somehow parse the file name from an URL parameter.

The contact form will need some kind of API and database behind it to handle the POST request when someone submits it and it's how well this part is written that's going to make or break things - whatever language you use, if it's a SQL database then SQL injection is worth looking out for; if the user's input is in any way echoed back to them or to the client in a webpage then (java)script injection needs to be considered and everything properly HTML-escaped. Compared to the contact form, using an include is as safe as it gets.

If you only wanted a set of webpages, not an interactive web application, the ultimate in security is to use a static site generator - the server only has to serve files which gives a much smaller attack surface.

So:

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Worded that way, almost none. An include-header script is certainly not a vulnerability. Having PHP installed in the first place when you don't need it is not best security practice, having it installed and not updating it regularly whenever security patches come out is a potential problem, as is not having a policy of who's responsible for these updates - after you've finished the site design will the client be in charge of this? Or the hosting provider? If the client is worried about that, they shouldn't have PHP on the server in the first place. If not, then there's no security-related reason not to use it in places where you know what you're doing.

Answer 8

Languages and tools aren't inherently insecure, bad code and security practices are.

Since php has a low barrier to entry, people that don't understand network security and secure coding can create security issues with uninformed decisions.

It's not the tool, it's the monkey using it ;-)

Code written in any language can be insecure.

Answer 9

"They are reluctant because they were advised by their hosting company that using PHP is a security concern which might allow someone to break into cPanel and gain control of the site"

If the hosting company think they need cPanel to run PHP then its time to move host