Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Mar 15 '11 at 14:14

This question came from our site for professional and enthusiast programmers.

35  
blame it on badly written online tutorials. more often than not, people are just copy and paste whatever code they find on the net. JavaScript is also another victim of such practice. –  kjy112 Mar 15 '11 at 14:12
33  
Blame the blogs. Oh, and W3Schools... –  Brian Driscoll Mar 15 '11 at 14:12
12  
Yes, absolutely W3Schools - see w3fools.com –  DisgruntledGoat Mar 28 '11 at 12:30
2  
I constantly see people warning about sql injection - so I dont even think the premise of this question is valid. It is a high priority. –  GrandmasterB Dec 19 '11 at 7:48
3  
What I'm seeing in a lot of the answers is the that it's easier to teach critically broken PHP than it is to teach, well, PHP that's not critically broken. You cannot accept that argument and still claim that PHP is not a bad language –  user16764 Dec 1 '12 at 0:00

11 Answers 11

up vote 32 down vote accepted

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.

share|improve this answer
8  
I've tried to correct such things elsewhere, only to be told that it's not relevant for the problem at hand. So because a lot of people prefer a simple hack to a slightly more complex good solution, bad examples are left alone. –  l0b0 Mar 15 '11 at 14:25
6  
Most people don't really care about SQL injection until they get hit with it. Then suddenly they're wondering where their tables went. –  Joel Etherton Mar 15 '11 at 14:39
1  
The other reason is that SQL injection is not always viewed as a relevant concern for internal apps. (Not that they're right.) –  John Fisher Nov 26 '11 at 4:59
1  
Don't forget that Answers are there to answer the question. Often it is pseudo-code (or SQL) that is intended to answer the question, not necessarily provide a safe and secure copy and paste solution (despite how the answer may be used in reality). –  Dalin Seivewright Dec 19 '11 at 18:52
1  
@l0b0 I know someone who got people to take SQL injection fixes seriously by actually demonstrating an SQL injection attack against the current production code. –  user16764 Dec 3 '12 at 18:32

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.

share|improve this answer
    
As you said, the problem is not perl or PHP, its that these languages let beginners do a lot of things, which is good, but don't always provide ways to do them well that are as obvious. –  Zachary K Mar 15 '11 at 15:48
1  
@ZacharyK: Isn't that then the language's fault by default? –  Lightness Races in Orbit Mar 15 '11 at 23:27
6  
@tomalak-geretkal: You use the word "fault" as if making it possible to get stuff done is a bad thing. The same characteristics that lead to lots of bad code also lead to a lot of real problems solved. It is not clear that this is a bad thing on the whole. –  btilly Mar 16 '11 at 0:26
    
Re 'fault': if HTML (or rather the browsers interpreting it) had been as fault tolerant as XSL, there would never have been a world wide web... –  Benjol Dec 19 '11 at 8:33

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".

share|improve this answer

Personally, I believe PHP is easy to use, so naturally it's easy to misuse.

share|improve this answer

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?

share|improve this answer
    
I didn't say anything about "all PHP programmers". –  Lightness Races in Orbit Sep 11 '13 at 15:45

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.

share|improve this answer
6  
That shouldn't be an aside. That should be part of the basic lesson. Possibly with a big, fat, warning about the wrong way to do things. People tend to cut and paste what they first see, and you really want that to be the right way to do things. –  btilly Mar 15 '11 at 16:40
    
Certainly in the .NET world parameterising is pretty straightforward these days and should indeed be 'page one' stuff. –  Alan B Sep 11 '13 at 16:32

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.

share|improve this answer
5  
It's certainly possible to over-engineer sites with complex frameworks that you just don't need. I'd say that Rasmus's suggestions verge on the criminally dangerous, but there's definitely a sane middle ground. –  Lightness Races in Orbit Mar 15 '11 at 23:27
    
nowadays using ORM isn't over-engineering; it's standard. So is using MVC pattern. –  vartec Mar 15 '11 at 23:54
3  
@vartec: It's hardly "standard" just because all the sheep are using it (and, for what it's worth, not even all the sheep are using it). For small scripts it can easily be over-engineering. –  Lightness Races in Orbit Mar 16 '11 at 0:40
1  
@Tomalak: it standard, because that's the way to implement clean and sustainable projects. "small scripts" tend to grow over time and turn into unmaintainable monstrosities. –  vartec Mar 16 '11 at 11:29
2  
@vartec: I think you've misunderstood the meaning of "standard". –  Lightness Races in Orbit Mar 16 '11 at 11:30

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

share|improve this answer
2  
There was a time it would escape ALL variables as if they were going into MySQL specifically, whether they ever were or not. Note to language designers: when you find yourself having to implement stripslashes(), you've already done it wrong. –  Dan Ray Dec 19 '11 at 13:14

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):

  1. This is how you set up a basic web page
  2. This is how you make the web page pull data from a database
  3. This is how you send data from a web page to a database
  4. This is how you make sure the right data is sent.
  5. This is how you protect your database from malicious data entry
share|improve this answer
    
that's more or less the way I was teached php +1 –  im_a_noob Sep 11 '13 at 19:04

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.

share|improve this answer
3  
Sorry, but absolutely no example code should ever mix mySQL queries with PHP. That's simply doing it wrong. –  Raynos Nov 26 '11 at 4:30
1  
And irresponsibly. –  Lightness Races in Orbit Nov 26 '11 at 10:48
    
-1 for most tutorial code I have written has little or no error/exception checking.. –  Yannis Rizos Nov 27 '11 at 1:50
    
I can see the OP's point. Irresponsible is, when an employer hires a guy who lacks knowledge about SQL injection and the like. –  Raffael Nov 27 '11 at 12:25
    
I think this approach is defensible if you include comments directly in the code saying "Do not use this in production!". That way the copy/pasters have no excuse. –  Benjol Dec 19 '11 at 8:47

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?

share|improve this answer
2  
But when you are teaching the language, you should still use the preferred APIs in your examples. Like always use the parametric form of SQL queries, possibly with a footnote like "Don't ever think of using interpolation to build SQL instead. It seems a little easier, but it's extremely prone to security vulnerabilities." –  Jan Hudec Nov 25 '11 at 12:00
    
Yep, good points. Footnotes would be a good reminder, and that goes for the online tutorials as well. In all seriousness though, it would be great if book authors of all languages could incorporate the advice from OWASP into beginner texts. Even just as a reference. The OWASP Foundation do a good job. –  Steve Rathbone Nov 27 '11 at 5:56
    
@indifferentDrum: You can teach people to drive with their feet, too -- doesn't mean it's a good idea. –  Lightness Races in Orbit Dec 1 '12 at 10:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.