PHP Tips, Resources and Best Practices for 2015

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.

5.5 is still better than the 5.2 floor more than a few projects are holding onto (Wordpress…)

very usefull, thanks for the informations here

The current version of WordPress may still run on 5.2 but it is intended to be run on 5.5.

On 5.5 it uses the mysqli database interface instead of the mysql one - as you can easily find out by turning the mysql interface off.

Unfortunately many WP installations is on shared hosting where they are probably affraid of upgrading.

Its crazy that only 10% of all WP installations is 4.1 and 32% of all installations is running on PHP5.2

Not everyonly is updating like the rest of us:)

It is all of the other sites sharing on the same server who need to be afraid of those not upgrading as not upgrading produces a potential security hole on the server.

No wonder WordPress has such a bad reputation if 90% of installs are not up to date.