Probably contrary to common belief here but the headline is correct IMHO.
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.
In contrast, I'd say a pure-C web page would be way easier to open to attacks than a PHP one.
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.
and a webpage written in assembly would be even more likely to be able to be attacked. Its a silly argument. No one is saying consider C for you next website.
Actually I am considering C. It's pretty easy to write a CGI that Apache can call. Process startup is pretty cheap on UNIX and it's secure if you suexec, chroot it and know how to write C code that isn't full of holes.
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.
I think one issue is that there are a number of somewhat dangerous foot-guns security-wise in extension-land. For example, last I checked the pgsql extension had implicit, global, anonymous database connections.
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.
I would be suprised if this is a revalation to many people. PHP itself has been pretty solid for a while.
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.
I think the fundamental question is how easy it is to shoot yourself in the foot without having any clue as to what you are doing wrong.. Comparing PHP to C is somewhat of a bad comparison since C is famous for security gotchas. If you are comparing PHP to C security-wise.... What's the comparison? All the security of C with all the performance of a scripting language?
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.
I would be genuinely shocked to hear anyone had made the point this article is arguing against since register globals was disabled by default. PHP is awful for all sorts of reasons, but the security angle here feels like a straw man.
I work with a group of penetration testers (who audit the security of websites, ranging from top 100 sites to smallish ones), we find a lot more issues with PHP sites than any other. .NET sites are often the most secure.
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.
That still does not mean the language itself is insecure. In my opinion this rather indicates the developers responsible for building those vulnerable sites lack some knowledge about proper web security.
I believe that was more or less the point he was making - regardless of the language or platform developers without proper understand can and will make security mistakes.
I agree, I think the problem is more so with developers that don't have a proper understanding and with what comes out of the box.
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
Sending database credentials to the browser btw may or may not make sense. It really depends on context. If the db is enforcing users' security (which would be the case if you want to share security logic across apps possibly written in different languages) and it is an internal app with limited numbers of users, this makes a lot of sense. For a public internet site, however, it makes very little sense (since you likely have lots of users with essentially the same permissions).
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.
It was only a single app, and the database server was pretty much unprotected. As far as I can remember it did most/all of its access controls via JavaScript - it was truly terrible.
Sure there are situations where it is OK, but as a rule of thumb it's not a terribly good idea.
> As far as I can remember it did most/all of its access controls via JavaScript
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....
Just because you tested more secure .NET site than less secure PHP sites doesn't mean that PHP is less secure. It means you tested more secure .NET sites compared to number of less secure PHP sites. If you flip a coin 10 times and you will get 10 tails it doesn't mean that the coin is broken or faulty. Random numbers are random.
> If you flip a coin 10 times and you will get 10 tails it doesn't mean that the coin is broken or faulty.
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.
With a sample of 10 that makes sense. We have done over 150 PHP tests over the last couple of years and the average number of issues is higher than other technologies. What would account for that bias?
I think there is a subtle, but important thing that the author is missing because, while objectively, PHP as a turing complete language(I believe) you can write basically anything in PHP both good or bad, there is the question of what the language/framework/tools/community allows for or encourages.
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.
W3Schools actually has some nice content. Of course they tried to lure traffic with the name confusion but I really think their content is useful for people wanting to learn basic HTML or Javascript (or PHP).
Anyone learning basics from W3Schools is likely going to have to unlearn the bad practices they learned there. Their PHP/MySQL tutorials teach bad coding.
Never heard of this language. But thanks for sharing. This is an interesting language. Not sure whether I should use it right away (always sort of tied to a certain language and ecosystem, in my case PHP) but at least we can get some inspiration from innovative approaches like this.
It's a research language and it seems very rough around the edges so using it in production might be a bad idea. That being said this is supposedly written in the language https://bazqux.com.
Probably answering my own question here but now I think of it, there is no language I can think of that catches SQL injection etc, but there seems to be server that does!
Its been a while since I did any ASP.Net, but I remember some sort of error that would be thrown by default for common sql injection or script injection patterns on user inputs. There were still many many ways to screw things up, but this probably prevented quite a few attacks for extra lazy/ignorant coders (we have all been there at one point or another).
Not a complete solution, but I thought perl's "taint" feature was a brilliant idea, and I wish more languages did similar. In short, data provided by the user is automatically marked as "tainted", and cannot be passed into a shell command, an SQL string, printed into the HTML, etc, without being explicitly converted into a safe form.
(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)
Haskell with Yesod comes as close as is practical (if you explicitly tell it a string is safe to use in a certain context, it will not magically figure out that you're wrong). If you loosen the requirement to just "secure by default" rather than "insecure code fails to compile", most modern web frameworks have built-in automatic CSRF protection and default to escaping all strings when inserting them into HTML.
That's a bit of a broad statement, maybe - I'd be interested to see a general purpose language that will not allow you to write insecure software, I have a hard time believing that exists.
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.
No. There are plenty of people that say PHP itself is insecure.
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.
Some languages make writing secure code easier than others. When it comes to web-related code of semi-good programmers, I'd conjecture that the amount of vulnerabilities is directly proportional to the amount of magic involved. Early PHP had lots of magic - things like register globals or magic quotes. By now no sane developer uses those things anymore (well, and they were removed). The plethora of recent Rails vulnerabilities was also caused by various magical behavior, especially in parameter parsing. (Actually, I'd expect modern Rails code to have more vulnerabilities than modern PHP code, because they still have a lot more magic involved.)
The most common vulnerabilities are in the frameworks and libraries surrounding a language, not the actual language (there are exceptions). On top of that, user/developer sloppiness is even more common than security bugs in common frameworks. I would bet most servers that get compromised do so through having things like root/password1 credentials or extremely obvious sql injectable code.
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:
The people who the software is for, end users, rarely care which language/framework things are written in.
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.
I think the point of the article is that most of the arguments made against PHP can be made toward any other language as well (i.e. you can write insecure code with it), so the defences can be made for any language as well.
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.
I am confused as to whether this article is trying to compare the security of the language implementations (PHP Interpreter, JVM, Ruby Interpreter, V8) or what vulnerabilities can be exposed in programs written in the language (SQL injection, non thread safe, stack overflows) etc.
What the article completely ignores is the fact that there are plenty of security issues in the implementation of the PHP interpreter. Just compare the number of security advisories for bugs in PHP itself to bugs in Python/Perl/Ruby/etc. There is a difference.
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.
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.
If you use square brackets in query string (passwd[$ne]=1) PHP converts them to arrays. I use them daily like (first=value&arr[]=foo+bar&arr[]=baz). I still can't see the problem with that. You should not trust any user-generated data. This is not a PHP problem.
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)
What you are saying is that it is your problem if you do not know PHP well enough to know everything that it is going to possibly do behind your back. And you say that in full knowledge of the fact that PHP is widely used by the exact kind of novice programmer who are least likely to be able to competently do that. And you fail to notice that those two facts combine for a recipe for a constant stream of security holes.
Figure those things out, and then you will understand why I think that PHP is worse for security than other languages.
"RTFM" is the correct response in this situation. PHP converts []s in url to arrays. You should know that, because you are the programmer. You should know your language. What if i send "anything' OR 'x'='x" as parameter? Does SQL injection also PHP's fault or does it programmer's?
When you compare with other languages, PHP does a lot more behind the programmer's back, has a far larger set of built-in functions (many of which have bad interactions) and has a user base with on average less experienced programmers. And yet you think that RTFM is the answer.
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.
That's what i'm saying. You shouldn't trust any data from sources like cookies, query strings and even http headers. If you blindly trust them, this is not a problem of programming language. You should sanitize data before using it.
The point is that if you build a data structure for MongoDB in any language other than PHP, and just include the user parameter where it belongs, the only thing that the user can supply there is a string and it is easy to verify that there is no possible security problem. MongoDB's APIs were designed around this fact as an easy way to avoid the possibility of SQL injection type attacks.
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.
So not understanding the language you are writing an extension for is more acceptable to you than allowing a basic but useful way to accept semi structured data in http requests?
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.
The big problem here is too many "overnight learn to code in 24 hours" developers choose PHP to develop by "cut & shut approach" using code they acquired online from a dingy website. This yields insecure implementations. And the cycle begins over and over.
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.
75 comments
[ 4.0 ms ] story [ 196 ms ] threadHowever 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.
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.
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.
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.
http://plv.csail.mit.edu/ur/
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.
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.
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.
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.
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.
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..