PHP is as secure as any other major language
acquia.com
acquia.com
In the earlier days of PHP, it was incredibly common to build SQL via strings and nobody thought too much about it. Over time things have evolved and a million little frameworks have sprouted up and it's less of a problem, but that doesn't mean that PHP doesn't have a terrible history behind it of a community not knowing or caring as much about security as they should.
Then, there is the fact that php files just sit on the server and can be executed arbitrarily by just navigating to that file. That is a real security problem in the case that someone is able to upload a php file to a machine. Yes, I know a lot of frameworks make this harder to do now, but by default apache/php lets you do this and you could argue it's one of the real strengths of PHP(ease of deployment).
Last, because PHP is the biggest language it is the biggest target, which means that writing secure code is that much more important. So many PHP projects are open source, so if a vulnerability is found and you don't upgrade your Wordpress or Drupal or Joomla or Magento or phpBB or whatever else app you are running, your site is very likely to be compromised just because you aren't staying up to date with updates, and A LOT of people don't update their software, systems, or packages like they should.
So, PHP from a purely objective standpoint might be as secure as anything else, but the human factors surrounding PHP make it a lot worse in my opinion than other languages/platforms/frameworks from a security standpoint.
1) You can write insecure code in any language, and
2) Platforms written in other languages have security vulnerabilities.
When your argument in defense of a computer language can be applied to every single computer language ever invented without any changes, it's a sign that it's not really an argument.
Here's my argument about how I'm as good at ping-pong as everyone else:
1) Other people can play ping-pong badly.
2) Other people have lost ping-pong matches.
We as developers can get too focussed on optimizing and making our own lives easier and the net output to the end-user is relatively the same.
This does not mean to ignore what's out there that's new, but if you see a platform re-inventing features and libraries that have existed already for years in other platforms, you might be in for a few years of patching together things.
It's unfair to say that a vague defense to a vague accusation is invalid. If I said you were the worst ping-pong player in the world because you lose some games I think the arguments you listed would be a valid defense.
Well this is patently false. You can find a significant difference in the vulnerabilities found with PHP interpreter and core libraries then you find with other languages.
It's not just that people program badly with it, it's a badly programmed language that sets users up to fail and even when they do program securely PHP itself is insecure.
Lets see how PHP compares....
PHP (348): http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id...
Python (17): http://www.cvedetails.com/product/18230/Python-Python.html?v... and also (20): http://www.cvedetails.com/product/2147/Python-Software-Found...
Perl (20): http://www.cvedetails.com/vendor/1885/Perl.html
Ruby (42): http://www.cvedetails.com/product/12215/Ruby-lang-Ruby.html?...
And so on and so forth. The only thing that rivals it is Java.
That being said, I once tested a ancient Java web app that recommended you use IE 5.5 (for the latest features). The people who made it decided it would be a good idea for the site to send the database credentials to the browser, which would then send them when requesting data. I face palmed pretty hard.
Microsoft provides a lot of security features that are backed into asp.net that are pretty trivial to enable. From what, little, that I know about php I am not sure the same can be said. I believe that would make a bigger difference about perceived security of a platform
In LedgerSMB, for example, we use app login credentials as db credentials for internal users, but for customer/vendor portals, we use a single user account for the portal. There are a lot of reasons for this but PostgreSQL is flexible enough one can (relatively easily) limit most users to the LedgerSMB app if one wants (via pg_hba.conf). The goal however is to allow non-web apps with the same credentials and security enforcement and we already have some of those.
So it isn't necessarily a facepalm. It really depends on context. There can be valid reasons for it but those are not in the context of a public-facing web site. I.e. if you expect users only to access the db through a single app then you don't want to use it but if you want the db to be accessed through a group of apps then using the db as a SSO technology is actually pretty smart.
Sure there are situations where it is OK, but as a rule of thumb it's not a terribly good idea.
Hahahaha. If you are going to use db credentials, for the love of the gods, at least consider using the db to enforce access controls...... That's just common sense, IMNSHO....
It might be. At a certain point, the coin is more likely "broken" (or rigged somehow) than actually flipping tails every time. The chances of flipping a coin 10 times in a row tails are ~1/1000, so I do not think this is in the range, but at 100 flips, I would say that it is much more likely that the coin has been tampered with.
PHP had a bad wrap for a good reason. It deserves it. Looking past the various naming inconsistencies etc, `register_globals` was a terrible idea. Then `magic_quotes` was hardly much better. Not to mention the numerous "tutorial websites" who ignore security altogether with their advice..
In recent years PHP has improved drastically. Unfortunately the stigma around previous version has persisted with many people ill informed about what modern PHP looks like.
Now, the core language in PHP is a lot better than it used to be but in the extensions you still see all kinds of braindead behavior like implicit (yet both global and anonymous) database connections and the like. Since so much of PHP is in extension-land this is somewhat troubling.
However this is because web programming as a whole is a crock from top to bottom. PHP doesn't really add or subtract from that other than lowering the barrier to entry with respect to compromising your server through stupid architectural or coding decisions.
If we wrote our web pages in C, it's be just as bad. Rails has a terrible history of vulnerabilities. Many times I've seen injection attacks in audited Java and C# applications.
Everything can be a turd in the wrong hands.
String copy issues (termination), buffer/array overflows, machine-code (R)CE vulnerabilities,... an endless list of stuff which the PHP runtime actually protects a novice of.
http://undeadly.org/ is written in C. Source: http://undeadly.org/undeadly-src.tar.gz
It's perfectly possible to write a pure C web page that is 100% secure. It just requires experience.
The same with all other languages. PHP doesn't protect the novice, neither does C. Experience does.
The same could be said about any language, however 'never use eval' is usually shouted quite loudly at anyone learning a scripting language.
I don't think that is true. PHP just makes it easy to write anything - including insecure code. And the bigger issue is that the community around PHP often shares code that is insecure without knowing that it is, or why that would be important.
The C argument is a red herring - its not meant for web pages. (web servers, though...)
Rails is not a language. It is a framework. Wordpress has tons of vulns as well.
I agree that "Everything can be a turd in the wrong hands", however, one of the biggest parts of, er, "turd prevention" is the culture and tribal knowledge around a language and best practices. PHP struggles with that because it is so easy to learn and so easy to do something bad.
Culture is part of it, but part of the culture is figuring out how to ensure that programmers can verify security. Yes, anyone can write insecure code in any language, but can anyone write provably reasonably secure code in a given language? That's a far harder question. I don't see PHP scoring very well in that regard.
The reasons are a combination of things. The language tries to volunteer to do too much for you by default. The environment it is run in tries to do too much for you by default. The past defaults were even worse. A lot of available software in PHP was written with no attention to security, and it still shows. And it has attracted a community that fails to recognize these things as problems.
Yes, in theory you can write PHP and make it as secure as anything else. In practice it doesn't happen that way. And until PHP developers stop patting themselves on the back and assuring themselves that they are really OK, they will continue to have big problems.
If you don't use prepared statements with PDO, i still don't see this as PHP's problem. This is a unqualified programmer problem.
refer to: http://www.phptherightway.com/#databases
In the case of MongoDB, a system that was designed to make SQL injection attacks a non-issue, in which they were a non-issue in other languages, were noticed several years later to suffer from SQL injection attacks in PHP and PHP only.
The cause is that the language, behind programmers backs, could let users supply a data structure where it looked like you'd only get a string. And would only have had a string in other languages.
PHP is not the only language with problems like this. For example Ruby on Rails about a year ago had a series of bugs that were due to a similar design flaw. But this type of mistake has, for years, been more common in PHP than in any other programming environment. And PHP programmers like you who think that they can just follow a couple of well-known guidelines for databases and be safe, who fail to understand when you are told directly that the problems are bigger, are a big part of why PHP continues to have these problems.
When programs volunteer to parse things in possibly unexpected ways, you tend to open up security holes where most people wouldn't expect to find them. In that situation, no matter how much you jump up and down and point the finger, the convenience of parsing is itself a real problem.
You've been pointed to a case where real programmers had real security problems stemming from PHP's willingness to parse when programmers using PHP did not expect PHP to do that because other environments don't. You fail to see that this is a problem with PHP, and only think of it as a problem with programmers.
Your willingness to accept that programmers should need to know more than they should, combined with an unwillingness to rethink your beliefs when presented with evidence that this has lead to real problems, is a perfect example of my point that PHP, "has attracted a community that fails to recognize these things as problems."
But i still say, if you expect a string from a query (address bar) but you don't type-check it before using it somewhere, it's your problem not php's. (by the way i'm a ruby programmer in my 9-5 work)
Figure those things out, and then you will understand why I think that PHP is worse for security than other languages.
Yes, programmers need to RTFM. Security isn't free. But PHP makes it much, much harder than it should be. And does so with a base of users who are not prepared to do it well.
If you want to get real security, you don't get it by simply saying, "Bad developer!" You do it with layering defenses. Developers who know what they are doing, using APIs that are clearly defined, with languages that do not introduce unnecessary potential security issues, with development practices that catch issues, with monitoring that notices stuff, and so on and so forth.
Yes, developers should RTFM. But if RTFM is the beginning and end of your thinking, you've got disasters waiting to happen. And the results are abundantly clear with PHP.
Now I'm done with this conversation. You are missing what should be a pretty basic and obvious point. PHP makes security harder than it should be. Not impossible. But harder than it should be.
Anything sent to a web app via HTTP is user generated content. You can't assume it is ANYTHING.
In PHP the exact same approach turned out to be a security hole because if the user supplies the right input you get a data structure that is meaningful to MongoDB.
As you say, you shouldn't assume anything about user generated content. But PHP's willingness to parse that input and turn it into something the programmer didn't expect to see often means that user generated content is harder to deal with in that language than you should reasonably expect it to be.
For several years if you followed the examples in the MongoDB docs, you wouldn't have known you had to, because the people who wrote those docs didn't know you did either.
"... you can write insecure code in it," he underscores his point,
"but that's a fundamental problem in every single programming language"
http://www.hiawatha-webserver.org/
I have no experience whatsoever with this beast but it says it kills SQL injection, XSS etc. Curious whether this would be effective.
Where is this wonderful language that throws compiler warnings when the code contains an SQL injection, XSS, or CSRF vulnerability?
(I'd particularly like it if it were possible for the user to define their own types, so we could have "raw string", "validated HTML string", "validated SQL string", etc - and also "distance in meters", "distance in feet", etc -- and it wouldn't be possible to operate on different types without explicitly converting them into compatible forms)
But you're coming from the right place - it's absolutely the job of the programming language to at least make it more difficult to do so and encouraging good security practices, and PHP does not do a very good job of that. Then again, I write JavaScript for a living so I suppose I don't have much room to criticize on that front.
Better languages have a far superior way to implement code following standard industry practices & conventions. For example, how many ways are there to get the length of a string in PHP vs say Python?
When there are too many ways to do some basic manipulations you start getting many different code implementations doing the same thing. Also how many Built-in Functions are included in PHP vs other languages? Too many is the answer.
Shall we even touch up on Unicode support? lol..
IMO it's just a bit easier to write buggy/vulnerable code in PHP than other languages. Or maybe I'm just a hater, don't know.
They are right.
Sure anybody can write insecure code in any language, but PHP makes writing secure code much more difficult then other languages and even if you do write secure code the interpreter itself has a pretty terrible track record.