On Stack Overflow, I see a lot of PHP code in questions and answers that have MySQL queries that are highly vulnerable to SQL injection attacks, despite basic workarounds being widely available for more than a decade.
Is there a reason why these types of code snippets are still in use today?
I think it's mostly due to a) ignorance b) laziness. Beginners usually don't know much about sql injection, and even when they hear about it, they ignore it because it's so much simpler and easier to code that way.
PHP deliberately makes it really, really easy for people who know very little to create useful dynamic web pages. This means that PHP is going to attract a lot of beginners, who create something useful, learn from other useful looking examples, and turn around to teach others how to do this cool, useful thing. The result is a lot of bad code, and a supply of programmers who don't know any better.
It only makes things worse that a large fraction of competent programmers want nothing to do with PHP. This reduces the base of experienced people who are willing to teach others better. But why do they avoid PHP? Well for a combination of factors. In part they don't like dealing with the language warts. And in part it is because they would prefer to work with good code, and there isn't a lot of good PHP out there.
This exact constellation of problems used to inflict Perl. As a shining example consider the case of Matt Wright, an enthusiastic teenager who set out to provide many useful, well-documented and easy to install CGI scripts back in the 1990s. Unfortunately he understood nothing about security, and neither did the people who wanted to use his stuff. The result was the Matt Wright Script Archives, which was an endless stream of security problems for early CGI scripts. Despite efforts like http://www.scriptarchive.com/nms.html, the problem didn't improve for Perl until shared hosting providers made PHP more convenient than anything else. That lead to the problem moving from Perl to PHP.
Unfortunately there are tons of more-than-bad PHP tutorials out there and some older PHP books also sucked at telling people to write proper code (not using register_globals etc.).
Additionally, with magic_quotes_gpc being enabled in the past, people didn't care about escaping because "it simply worked".
Personally, I believe PHP is easy to use, so naturally it's easy to misuse.
As a human, and a programmer, I find it remarkably easy to make mistakes, and overlook certain things, especially when pressed for time.
It's easy, and perhaps all too tempting, to blame a certain language, for being too accessible for its own good. But that would be glossing over the larger problem of human fallibility, regardless of the language chosen to program in.
Granted, we've come a long way since assembly language, and I think I would be far more productive programming in a more modern language, such as PHP, Python, Ruby, or Java.
PHP (and other scripting languages) have in fact lowered the barrier to entry. That may mean that more newcomers to programming try PHP first. But that certainly does not also mean that all PHP programmers are somehow less qualified, or less able to learn from their mistakes than programmers of other languages.
Rasmus Lerdorf created PHP in its original form back in 1994, it has evolved considerably since then. In its most modern incarnation, it supports object oriented programming, as well as superb frameworks, such as Symfony. PHP as a language has broken free from its original constraints, and has grown to offer great flexibility in how programmers can choose to use it. You can use it to create a 9,000 line script of spaghetti code, or you can use it within the context of a modern, MVC framework, such as Symfony: it's your choice!
I strongly suspect that security vulnerabilities are not restricted to a single language. It's tempting to write off all PHP programmers as somehow less capable, or more prone to writing insecure code. But I wonder how much of that is language bias, and how much of it is fact?
I think part of the problem is people who simply copy code without bothering to learn what they are doing, but really to my mind the way we teach porgamnming is broken and it is one of the reasons why there is so much bad code. We teach syntax out of context and so the beginners don't know when to use something and when not to or what problems the syntax is intended to solve and what problems it is not intended to solve. SO they use a hammer when a wrench would have been the better tool.
So for instance instead of teaching just syntax, you organize the course like (Clearly there would be more steps, this is just a basic example of building from basic to more complex problems rather than just teaching syntax):
I think you'll find a similar amount of MS SQL + ASP/ASP.NET examples that are just as vulnerable.
I feel the problem partly stems from the fact that when you're trying teach something, say filtering data using a WHERE clause, then you really don't want to clutter your example by properly escaping your query string or using a parametrised command.
I've been training developers for many years and I can empathise with people who write horrible code in tutorials. Sometimes that's the most easily understood. However, on an aside I always point out code that's vulnerable and make it into an interesting side topic.
PHP's original author, Rasmus Lerdorf, in his infamous blog entry advocates "no-framework" development. Although for SQL queries he uses PDO, so there is no risk of SQL injection. Still quite ugly and obsolete comparing to modern MVC frameworks with ORMs layers.
You can blame this poor practise on PHP itself. Legacy versions of PHP (up until circa 2006) would escape all GET and POST input variables so that they were suitable for database query interpolation BY DEFAULT. See http://php.net/manual/en/security.magicquotes.php
Don't confuse the purpose of a tutorial, which is to demonstrate something simply, with what should be done in a production environment. For example, most tutorial code I have written has little or no error/exception checking. I try to remind the reader that the code only demonstrates how to perform a specific task, not how to cover all the possible outcomes.
When i was learning PHP i looked at some these PHP+MySQL books, and yeah i feel that it contributes to that bad practice. But i have sympathy, becuase they are teaching the language, not good programming practices. Otherwise where would it end?
