PHP Tips, Resources and Best Practices for 2015

No it isn’t - as the article states, many people write insecure programs using PHP but PHP itself is as secure as most other programming languages.

There is a huge difference between insecurity being built into the language and people simply writing insecure code using a secure language.

One of the biggest problems is that almost all books and sites teaching PHP do not include the code to make their example scripts secure in order to save space and to make the code being discussed easier to see. The people learning mostly assume that the code they have been taught is sufficient and so they leave out the other 80% of the code they should be writing that handles the security aspects.

There are books available on PHP security that specifically teach you how to write the code in a secure manner and if that approach is followed then PHP is as secure as any programming language can be.

6 Likes

Now yes. Back in the days of register globals et al, not so much.

2 Likes

I think a main cause for so much poor PHP code is

OK, maybe some don’t copy-paste, it works, great! next. But I fear many do.

2 Likes

That still has nothing to do with how secure PHP itself is. Sure many programs written in PHP are insecure because they omitted all of the validation and other security features but the article is referring to PHP itself as being secure - the code used to write PHP does include all the security features - you can write insecure programs in any language.

There are far more amateur coders writing in PHP than in most other programming languages - that’s why so many programs written in PHP are insecure. The insecurity is in the way they write their code - it isn’t built into PHP and those who know how to program properly can write programs in PHP that are just as secure as programs written in other languages.

5 Likes

Exactly. I agree with that entirely. I’ve seen some really really insecure .NET applications in my life time. I’ve fixed a lot of insecure .NET applications. Same with Ruby, Python, Perl, PHP. It doesn’t mean the language itself is insecure, it simply means the programmer didn’t do their due diligence.

However. It can be proven that PHP among other languages (.NET, Ruby) do have security holes within the language itself. That’s what patches and updated versions are for though…

4 Likes

I imagine that the fact that PHP is so ubiquitous plays a major part in why it’s potential security flaws come to light more so than other languages

4 Likes

PHP hasn’t had noticeably more security holes in the language itself than any other popular programming language though.

4 Likes

Every kitchen has a knife.
You can use it to poke out someone’s eye, to cut your veins, to damage your household.
Why you’re allowed to have it at home is because a basic knowledge of its use is assumed.

If given basic security training in PHP via the resources linked in the original article, one becomes basically proficient in PHP security measures.

Much like you don’t let a child stab itself to find out knives are dangerous, so shouldn’t you let a rookie developer sabotage themselves with bad, outdated resources. As a PHP developer, it is on you not only to develop, but to educate those around you and to help spread good practices by means of, at the very least, referring them to proper sources.

Like the others said - every language is as insecure as those using it make it.

9 Likes

That’s not actually the case.

During 2014, PHP got 32 CVE IDs assigned, Ruby got 3 and Python 6.

While most of the PHP’s bad reputation comes (as mentioned here) from bad programming habits, bad code examples, bad books and so on, it is a fact that the PHP language itself has had more vulnerabilities than, say Ruby lang and Python. So based on that, I can understand why some might want to call PHP “insecure language” (it is not as “with no foundation” saying as many PHP devs may at first glance think).

When you compare the number of people actually using each of those languages (and therefore the need to actually find and fix security holes) that actually makes PHP the most secure of those three languages s there was far more than ten times the incentive to find security holes in PHP.

Windows always has far more security holes found and fixed each year than any of the alternative operating systems which is why Windows is many times as secure as ANY of their competitors.

All software has security holes - the more that are found and fixed the more secure that software is.

3 Likes

It’s probably going to take the removal of the “legacy” mysql_* functions by hosting companies from their servers before some people finally migrate over, tbh it’s about time that hosts started to remove the mysql_* extension from their servers as people and companies have had enough time to get their code migrated over to using the mysqli_* extension or PDO (my personal preference is to use PDO).

The other thing that I see is where people are letting user-submitted data near the database without sanitizing it and at the very minimum escaping it, tbqf the use of prepared statements should really be the norm now.

I know that some of my own scripts need more sanitizing added to them, sometimes I see scripts where there’s been no attempt at sanitizing the user-submitted data.

I don’t think it is that simple to justify that “PHP is the most secure of them”. All of the three (PHP, Ruby Python) are “mainstream” languages with huge user bases. While PHP has the largest user base, it doesn’t mean that Python or Ruby lacks security audits or research, or that research towards PHP is superior compared to Python or Ruby research.

And it is not only about plain user base size. Some other important factors are bounties offered/paid, importance of the victim, and quality of the audits.

I’m not saying one could justify which language is the “most secure” just by looking assigned CVE IDs, but I think, in this case, it gives some view.

Also, it is important to acknowledge that while software gets more secure immediately a vulnerability has been patched, but the other side is that the exact same software has been insecure as long as the point when the vulnerability was introduced in the code to the point it was fixed and deployed to the “end user” (which could be quite a long times).

1 Like

I totally agreed with the fact that “PHP itself isn’t insecure”, it depends on how you code in it. I have written most vulnerable code in my life and rewritten quite couple of times. No one cannot bet that PHP doesn’t/didn’t have any flaws/security holes but they are found, reported and fixed quite soon after its release because it is quite popular and holes are found on time.

If someone doesn’t upgrade the fixes on time then that’s not PHP’s problem ! Be updated and write code securely, otherwise your child can get the knife and cut anything.

No language is responsible for insecure application but the developer who codes it and doesn’t take care of it. generally speaking, don’t blame others for your incapability. Is there any proof that, hackers only hacks or hacked sites or application written using PHP but not written in other language? Probably not then stop blaming any language.

That’s true. But some languages make it harder and some make it easier to write insecure code. PHP is just so shockingly inconsistent with a lot of features added on top later in its life that it really makes it very easy to write shitty code. Add to that an abundance of very outdated tutorials and books and virtually unlimited number of inexperienced developers giving poor advice and it becomes a big problem.

As those people progress to writing code in other languages the number of improperly written applications in those other languages will increase. The issue is that so many people write PHP without having learnt how to write programs properly in the first place and as you say, these people without any idea of how to write proper programs then advise others in how they too can write insecure garbage.

Being able to code properly is independent of the programming language used. Unfortunately since the portion of the code to make it secure is generally around 75% of the total code and this part of the code is not necessary for working examples it usually gets left out of most books teaching programming. Experienced programmers know this and will add all the extra code needed but many newbies never get beyond writing example code never intended for a live environment.

PHP actually makes it relatively easy to implement most of the security needed. All you need to do is to avoid moving $_POST and $_GET values (etc) out of those arrays without validating the values first. That takes care of about 50% of the security issues that most newbie code has without even applying any security measures (since you need to do that to prevent junk input anyway).

I totally agree with your comments on PHP versions. Projects should not support PHP versions that are no longer officially supported by PHP. It dissuades people from upgrading and as you say, damages the entire ecosystem.

Once official PHP support for a version is dropped, so should project support.

I think that minor versions of projects (or major versions of software with rapid dev cycles) should start with a minimum of whatever PHP version is oldest current and stay with that for its life cycle. Hence if Drupal 8 where to go gold today it would support PHP 5.5 until 8.1 is released.

I think there’s equal chance of people having 5.5 and 5.6 installed - both suffer from a lack of exposure. I’d go with 5.6 off the bat.