143

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?)

Yumecosmos
  • 1,373
  • 2
  • 9
  • 8
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/41822/discussion-on-question-by-yumecosmos-hosting-company-advised-us-to-avoid-php-for). – Rory Alsop Jun 29 '16 at 16:42

9 Answers9

203

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.

Alexander O'Mara
  • 8,774
  • 6
  • 34
  • 38
  • 1
    Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/41900/discussion-on-answer-by-alexander-omara-hosting-company-advised-us-to-avoid-php). – Rory Alsop Jul 01 '16 at 11:26
137

"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.

Community
  • 1
Luis Casillas
  • 10,181
  • 2
  • 27
  • 42
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/42135/discussion-on-answer-by-luis-casillas-hosting-company-advised-us-to-avoid-php-fo). – Rory Alsop Jul 06 '16 at 19:32
46

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.

Community
  • 1
Machavity
  • 3,766
  • 1
  • 14
  • 29
  • 22
    _Build your own server (VMs are cheap)._ - Only do this if you know how to admin a Linux machine, or the administration is (competently) done for you. People having VMs with no clue how to make/keep them reasonaby secure is a significant problem in itself. – marcelm Jun 28 '16 at 20:15
  • 3
    @marcelm True, but at least you can work with your own VM, as opposed to a host that won't upgrade anything – Machavity Jun 28 '16 at 20:45
  • 15
    The idea that all languages are equal from a security perspective is just wrong. Saying you can fix the issues doesn't make it the same as a language that doesn't have them or requires you to actively introduce those issues. – JimmyJames Jun 28 '16 at 21:11
  • 1
    @JimmyJames I never claimed all languages are equally secure. But PHP is actively developed and, if patched and set up correctly, can be quite secure. The OP was asking if PHP is inherently insecure, which it is not. – Machavity Jun 28 '16 at 21:53
  • 13
    "Someone who tells you PHP is insecure is just being lazy." -> I totally agree with that! – Josip Ivic Jun 29 '16 at 09:30
  • 1
    Unpatched systems don't make PHP insecure alone. Just because a version of PHP has a security flaw, doesn't necessarily mean the code you are executing with that version of PHP will make your site vulnerable to that security flaw. You'd have to make use of whatever code is vulnerable in order to fall victim to the security flaw. If it's a flaw that can be exploited regardless of your code, then sure. – crush Jun 29 '16 at 23:04
  • 17
    "Someone who tells you PHP is insecure is just being lazy": Or is being realistic about the laziness that will happen. I mean, it's also possible to write a secure website in raw assembler, but realistically it's very likely not to happen. – ruakh Jun 29 '16 at 23:09
  • Most of these factors exist in other languages too. How on earth is MD5 anything to do with PHP ? – mckenzm Jun 30 '16 at 03:12
  • 3
    Also [very insecure]: using `unserialize()` on external input [the most common actually exploitable attack vector]. PHP has a bunch of _vulnerabilities_, but they typically are hardly exploitable under real world conditions. – bwoebi Jun 30 '16 at 19:35
17

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.

munkeyoto
  • 8,682
  • 16
  • 31
  • I'd be careful about claims of equation with Java without qualification, because having the JRE installed (more so if it's also enabled) is a security risk for clients in and of itself, much less the server. – Nate Diamond Jun 28 '16 at 19:15
  • 22
    .Net's not a programming language.... Is the article reputable? – Joshua Grosso Reinstate CMs Jun 28 '16 at 19:51
  • 7
    @BalinKingOfMoria, when someone says ".Net" in the context of programming languages, they're usually referring to C# with the .Net/CLR runtime. Occasionally they're referring to Visual Basic.NET with the .Net/CLR runtime. – Mark Jun 28 '16 at 20:48
  • @Mark It just strikes me as odd that not only would they not use the proper name, but that they also didn't capitalize it properly. – Joshua Grosso Reinstate CMs Jun 28 '16 at 22:40
  • 1
    @NateDiamond: My guess is that it refers to [JAVA servlets](https://en.wikipedia.org/wiki/Java_servlet), which does not requires JRE installed in any client. – lepe Jun 29 '16 at 02:37
  • 3
    .net is the same low level language no matter if you write it with c#, VB, php, f#, etc... – dandavis Jun 29 '16 at 05:48
  • @lepe Good point, though it does require it to be installed on the servers themselves, which is still a threat vector. – Nate Diamond Jun 29 '16 at 15:31
  • 12
    So looking at the report you referenced, it says 11% of the sites were PHP but that 15% of the vulnerabilities that were found. That's an over-representation of 36% more than what you would expect if you assume vulnerabilities should be equally distributed across languages. Java and .NET are also over-represented in the vulnerabilities but only by 12% and 11% respectively. By that metric, PHP has (by far) the worst stats in that report. – JimmyJames Jun 29 '16 at 16:24
  • 18
    To me this answer is like saying that all cars are equally safe, it's just that the knucklehead drivers are the problem! I think it's inherently inaccurate to talk about a language without talking about the ease of making hard to find errors in that language. PHP is weakly typed, and this leads to making mistakes you'd never make in another language. In essence, the language ALLOWS you to make these mistakes. Putting all the onus on the developer to write perfect code is a mistake, and saying it's purely a coding problem misses the point. Coder and language are not so easily separated. – Steve Sether Jun 29 '16 at 21:40
  • 8
    It's interesting to note that PHP sites "do not have a tendency to be as large or complex as .NET or Java sites but still suffer from many of the same issues". So basically despite being noticeably simpler and less complex, PHP sites had just as many vulnerabilities as the more complex .NET or Java sites. That's like noting that a one million LOC application had similar absolute numbers of bugs as a 100k LOC application and then concluding that both are of similar quality. – Voo Jun 29 '16 at 22:02
  • 3
    @Voo "So basically despite being noticeably simpler and less complex, PHP sites had just as many vulnerabilities as the more complex." Actually, it's worse than that. As I noted above, a disproportionate number of the vulnerabilities were found in sites built with PHP. So based on this report referenced these sites are simpler and have **more** vulnerabilities per site. – JimmyJames Jun 30 '16 at 14:38
  • 2
    Before you say it is "just as secure", please read [this article](http://phpsecurity.readthedocs.io/en/latest/_articles/PHP-Security-Default-Vulnerabilities-Security-Omissions-And-Framing-Programmers.html) - Special URIs and other features may enable vulnerabilities, and if you look in the PHP documentation, they **do not even mention those XML vulnerabilities that can happen with untrusted input**. Contrast this to Python, just for example - The main page of their [xml docs](https://docs.python.org/2/library/xml.html#xml-vulnerabilities) show possible vulnerabilities for each supported parser – NoBugs Jul 01 '16 at 02:00
  • 6
    As programmer I strongly disagree with the statement that PHP is no more nor less secure than other languages. It is not that you cannot write secure programs in PHP, it is just that PHP makes it unreasonably difficult while making it ridiculously easy to write insecure programs. – David42 Jul 01 '16 at 03:27
  • @dandavis .NET is not a language at all, that's like saying IBM PC is a language. The low-level language that most other .NET languages compare to is CIL. These silly confusions help noöne. – Luaan Jul 01 '16 at 11:32
  • @NoBugs The PHP manual is maintained independently of the language, although it's a pretty awesome official resource compared to some I've seen. Feel free to contribute a page on XML security. Now, as to whether anybody will actually *read* and *understand* the docs, in either PHP or Python, that's a different question... – IMSoP Jul 01 '16 at 12:13
  • 2
    @IMSoP _Sams Teach Yourself PHP, MySQL and Apache in 24 Hours_ is also a useful resource but it actually recommends not escaping when you query with a SELECT statement - search for "SELECT" and look at the query on 384 (`"SELECT fax_number, type from fax where master_id = $_POST[sel_id]"` and [other pages.](https://books.google.com/books?id=2hm3ScwClKIC&q=SELECT+WHERE#v=snippet&q=SELECT%20WHERE&f=false). If people who write PHP reference books don't know the best way to query, why do we expect average Joe PHP programmer will? – NoBugs Jul 02 '16 at 14:48
  • 2
    @SteveSether your analogy with cars is very far off and you don't supply any arguments why a weakly typed language is by definition insecure or less secure. not to mention that there is no accepted definition of what weakly typed means – Claudiu Creanga Jul 02 '16 at 18:52
  • 1
    @ClaudiuCreanga Please read "PHP is a fractal of bad design" for actual arguments. The point I'm trying to make is to give a general idea of the problem. Real arguments can't be done in a comment. – Steve Sether Jul 02 '16 at 21:51
  • @NoBugs So, to counteract my suggestion that the manual not be considered part of the core language, you widen the definition further so that PHP as a language is apparently responsible for the output of every publishing house in the world? I'm sure there are awful Ruby and Java books, too; I'm not sure what that proves. – IMSoP Jul 04 '16 at 09:00
  • 1
    @IMSoP Honestly I don't think I've seen such mistakes in Ruby and Java books/docs, that is exactly my point. For best security there needs to be a consistent culture of considering everything that x/y/z library could possibly do, and might do unexpectedly that seems to not be so much a part of the PHP user culture. Take for example the recent Magento hacks, the core of which was that it ["validates admin sessions only if a request contains the ‘/admin/’ prefix"](http://blog.checkpoint.com/2015/04/20/analyzing-magento-vulnerability/) – NoBugs Jul 05 '16 at 00:19
  • @NoBugs I wouldn't say that's really "the core" of the attack: "These well-implemented safeguards really constrain our attack surface, and we could not find any critical (RCE, LFI with no suffix) vulnerabilities with this approach." Ultimately, they had to work pretty hard to find an SQLi vulnerability and chain a whole series of attacks to exploit it. I don't see that as any more evidence of "insecure culture" than, say, allowing JSON input to eliminate WHERE clauses in your ORM: https://groups.google.com/forum/#!topic/rubyonrails-security/t1WFuuQyavI – IMSoP Jul 05 '16 at 09:02
8

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.

fluffy
  • 1,342
  • 1
  • 8
  • 10
3

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.

HashHazard
  • 5,105
  • 1
  • 17
  • 29
  • 14
    Wordpress *is* a security risk. Even the core has horrible coding practices and a long history of vulnerabilities. – Jacco Jun 28 '16 at 19:38
  • 2
    @Jacco True, but there is bad code in the bowels of lots of applications. WordPress is primarily targeted because it's popular. The core has undergone some improvements in the last few iterations, though still far from perfect. – HashHazard Jun 28 '16 at 19:42
  • Name a popular application/system that doesn't have a long history of vulnerabilities. oh yeah android – Claudiu Creanga Jul 02 '16 at 18:42
  • 1
    @ClaudiuCreanga Really? *[android](http://androidvulnerabilities.org)* is the example you're going to use as a system without a long history of vulnerabilities? – fluffy Jul 04 '16 at 19:40
3

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.

  • "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"... Was afraid of that! Unfortunately it's shared hosting, so not much of a choice in that matter. :/ I have to learn more about server side includes, thanks for the tip! – Yumecosmos Jun 28 '16 at 17:57
  • 6
    @Yumecosmos If it's shared hosting, the other tenants of the hosting service are a far greater risk than PHP itself. Shared hosts are generally reluctant to install something for just one of the many (sometimes thousands) tenants and will come up with all sorts of reasons to avoid it. A simple "you're on shared hosting, what you see is what you get" would be more honest (and entirely fair). – ceejayoz Jun 28 '16 at 18:27
  • 2
    @ceejayoz To that point, almost every time my site has been hacked it's been through another site on the same shared hosting as a vector. There are definitely things you can do to limit that possibility, though, like being very careful about your file permissions and so on. I have a nightly cron job that verifies my file permissions and detects md5sum changes on all my files and a few other things. – fluffy Jun 30 '16 at 18:08
2

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.

Neil Davis
  • 282
  • 1
  • 4
  • 9
    Languages may not be inherently insecure, but they *can* have proper security principles deeply ingrained in their design. PHP *doesn't*, and that's an understatement. See https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ – Wildcard Jun 30 '16 at 05:01
  • 2
    And that's why everyone should go learn Python! Sorry citing "this other language sucks so learn Python!" sites is bad form. You can write garbage in Python too. I've fixed tons of it. Python isn't a magic bullet for incompetent programmers. You write code using the language your employer has standardized on, or in my case, what the client wants. I'm agnostic myself. I code in Python, php, Java, .net, Perl, and even maintain some old cold fusion sites. Please don't hijack posts to push the Python agenda. – Neil Davis Jun 30 '16 at 12:05
  • 6
    *I* didn't mention Python anywhere. I haven't even *learned* Python yet (though I'm about to). How in the name of common sense you can interpret my previous comment as "pushing the Python agenda" is baffling. But your answer here basically adds up to "No language is any more secure than any other language," which is nonsense. ([This answer](http://security.stackexchange.com/a/128601/96753) provides some specifics as to why.) – Wildcard Jun 30 '16 at 17:59
  • 2
    You provided a link to a rabid Python evangelists opinion – Neil Davis Jun 30 '16 at 18:05
  • 3
    @user356540 The very first thing eevee says about Python: "I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I don’t claim it’s perfect; I’ve just weighed its benefits against its problems and concluded it’s the best fit for things I want to do." That is not the same thing as being a rabid Python evangelist. – fluffy Jun 30 '16 at 18:10
  • 1
    The main page of the Python [xml docs](https://docs.python.org/2/library/xml.html#xml-vulnerabilities) show possible vulnerabilities for each supported parser. While PHP also has those vulnerabilities, they do not mention that on the [xml reader docs](http://php.net/manual/en/book.xmlreader.php). :( Unfortunately even common PHP books have examples with sql injections. – NoBugs Jul 01 '16 at 02:10
  • 1
    "You can write garbage in Python too". That's a strawman. The argument is that PHP makes it hard to write correct code for the myriad arguments (remember `register_globals`?) mentioned here and elsewhere, not that you can't write bad code with other languages too. – Voo Jul 01 '16 at 09:03
  • 2
    None of these comments invalidate the points in my original answer. You can code securely in any language. The reverse is also true. It's up to the programmer to know their tools and code securely. If you think any language will do this for you, you don't understand security. – Neil Davis Jul 01 '16 at 14:40
  • +1 overall, but; why does everyone assume/state PHP has a low barrier to entry and how does that relate to network security? And what is that compared to? Ruby, Python, Java, C, Perl? I will concede that Perl has a higher barrier, but most of the Ruby/Python evangelists brag about the fact that there language has a lower than normal entry point. And to be honest, I think typed languages like Java have a lower entry point than un-typed. In fact, when I code in PHP, I type everything. I would say that PHP has a higher entry point than most other languages around its age. – Jdahern Jul 01 '16 at 18:47
  • @Voo that one is long dead in php. every language has dead insecure functions – Claudiu Creanga Jul 02 '16 at 19:09
  • 1
    @Claudiu It was in the language for something like a decade (and only removed in 2012), even as the default. Name one deprecated feature that approaches the same level of insanity in any other mainstream language. The point is: If you had proposed something like this in any other mainstream language, it would've been shot down immediately. – Voo Jul 03 '16 at 20:27
1

"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

twigg
  • 721
  • 1
  • 5
  • 5