PHP has had many reputations over the years, but being insecure as a language never really was one of them.
The core team, all its faults notwithstanding, is rather quick in pouncing on all security matters, and updating PHP to the latest version will often allay all worries. But the end users, such as we are, tend to mess things up. We don’t update, we use outdated packages or packages with holes in them we’re not aware of, we use ancient extensions… we expose ourselves to risk in some truly creative ways.
Tips, Resources and Best Practices
Let’s start 2015 off right, shall we? This post will list important resources you should have in your brain/toolbelt before building anything with PHP in 2015. I’ll do my best to keep this post up to date, so it stays relevant indefinitely, but, like I said, I’ll need your help.
Keep your PHP up to date
When I wrote about the cancer that is legacy code, I focused on application code. I still firmly believe that you should never develop for the lowest common denominator, else you risk becoming the very thing that’s holding your language’s progress back. That’s not the focus of this section, though. Recently, a new version related discussion ensued.
Only day 2 of the new year and the mis-statement of the year may have been made. PHP is infamous for being insecure. The core has improved, I’ll grant that, but the community surrounding it still doesn’t take the issue seriously. That’s not unique to PHP, but it seems worse among PHP progammers. The language itself does little to nothing to help users avoid these problems - loose datatyping is a hacker’s dream for causing all sorts of havoc. It wouldn’t be so bad if you could turn it off.
I can’t be too critical of PHP - it does pay my bills - but don’t call it something it never has been - secure. It’s not - you have to watch it and the programs ran using it like a hawk.
There’s to many PHP legacy tutorials out there on the internet, every day you see people who are new to PHP ask for help on script for they are learning PHP for the first time and found this tutorial on the net or it’s obvious they had for I spot is msyql instead of mysqli or PDO. Then you explain to them that mysql is obsolete and that you should choose one of the two alternatives. You get one of two responses.
First response - “Oh I didn’t know that, Thanks for pointing that out”
Second response (This one irks me to no end) - “Oh I know that, but I just want to get my script to run. I’ll go back later on and change it when I have the time”.
I see that second reponse a lot and sometimes you get even a worse response than that, something like “I don’t care, I just want to get my script to work”. The later group of people is a lost cause and the ones who say they will go back when they have the time, I doubt that they ever will. It is not just that the make for PHP insecurities, for it’s other aspects of programming in PHP that make it insecure. A lot of people have this way of thinking - “If it is on the internet, it must be true” mentality.
I still remember what it was like when I was new to PHP and spent long hours on a script only to ask help on it to get the reply - “You best to throw that code in the trash and start over for that has more security holes in it than Swiss cheese does”. The first inclination is to get defensive about it, but after a cooling of period you realize that the person was only trying to steer you in the right direction. It’s better to get a better grasp of PHP by doing it the right way the first time and I have learn before tackling something new in PHP to ask if I starting off the right way. Thus, hopefully avoiding spending needless hours on PHP code that is a pile of junk. That is my opinion why PHP can have a bad reputation, for there still a lot of legacy code still out there on the internet masquerading as helpful tutorials.
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.
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.
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…
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.
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.
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).
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).
