Hacker News Reader

I can totally sympathise with the slightly angry tone of this reply, as my post was in a similar vein so I kind of had it coming. You're correct in that this was kind of just a cheap shot and I agree that the community is at least heading in the right direction. You could easily argue that if I really feel so strongly about this issue, I ought to be contacting codular to discuss the issue instead of idly bitching behind their backs on HN.

I do disagree with you on some of your points about tutorials though. You claim it's possible to find such insecure example code for any language, and that's probably true. But is it easy? The first search result for "python mysql tutorial" [1] doesn't contain any SQL injection vulnerabilities. Neither does the first result for "ruby mysql tutorial" [2]. All seems well with "java mysql tutorial" [3] too. Surely the first Google result for "php mysql tutorial" [4] can't be that bad then?

    $first=$_POST['first'];
    $last=$_POST['last'];
    $phone=$_POST['phone'];
    $mobile=$_POST['mobile'];
    $fax=$_POST['fax'];
    $email=$_POST['email'];
    $web=$_POST['web'];

    mysql_connect(localhost,$username,$password);
    @mysql_select_db($database) or die( "Unable to select database");

    $query = "INSERT INTO contacts VALUES ('','$first','$last','$phone','$mobile','$fax','$email','$web')";
    mysql_query($query);

Ouch. In this case, your point about this being an "old and awful" tutorial does apply. But the tutorials from my original post are new, as in "2013" new. And they were on the front page of HN not one week ago. It's like, finally here comes a fresh-looking new site that looks like it might even have a shot at knocking that garbage from "freewebmasterhelp.com" off the top spot on Google, and it's still not as good as it should be.

[1] http://zetcode.com/databases/mysqlpythontutorial/

[2] http://zetcode.com/db/mysqlrubytutorial/

[3] http://www.vogella.com/articles/MySQLJava/article.html

[4] http://www.freewebmasterhelp.com/tutorials/phpmysql/4

The tutorial you linked to shows a date of 1999-2001 (not 2013...). Considering the origins of PHP being predominantly a templating language targeting "webmasters", it's understandable that this link is at the top of the search results. Unfortunate, yes, but understandable.

However, PHP is no longer a templating language. It's a full featured programming language that is used to build a variety of different systems. Trained developers work with PHP every day to build solid, testable and secure code.

There is no excuse for any trained developer to write code like that. Perhaps you shouldn't judge the language just because some untrained idiot put up a bad tutorial.

"Posted Last Monday by Michael"[1]

1. http://codular.com/implementing-pagination

I wasn't angry and didn't mean to come off that way. Text man, emotions just don't come through... unless you use emoticons... which I never do.

But anyway I think we might just view tutorials differently. To me, what's posted above is an outdated, insecure way to put data into a database but it definitely answers the question "how do I put stuff in a databse" simply and right to the point. And that's what I like about PHP tutorials. I'd rather put the onus on the programmer to learn how to put "way to do X' and "way to do Y" together on their own rather than muddy the waters with "here's how to do X but this is important too so let's show you how to do this other thing at the same time".

I just took a quick peek at the Java and Ruby tutorials you linked, and indeed they both talk about prepared statements. Unfortunately for PHP, so many of the tutorials that are still around are very old. We have the same issues with Javascript. If one uses Google to search for a solution to a JS problem, often she or he is confronted with a solution from 1999... which is FAR from today's "best practices". Finding a 10 year old page discussing Python or Ruby connecting to MySQL is nearly impossible due to the newness in these languages in the web arena. (Yes, Zope existed way back when.)

I do agree that the above example is the rule rather than the exception as most books I've owned show something similar or worse:

foreach($_POST as $key => $value) { ${$key} = $value; }

That's almost as convenient as that magic global form garbage they used to have turned on by default.

I was under the impression though that the MySQLi adapter and PDO both made use of prepared statements. All we need to do now, is clean up the last few years of cruft/misinformation still floating around.

Regardless of the state of PHP itself, the user base is severely misinformed and a large part of the blame comes to rest on people writing tutorials like this.

Python, Ruby, Perl, Java and even C# all have popular, widely used SQL interface libraries where placeholders are the norm. Only PHP even considers injecting user data into queries. This is extremely harmful.

Tutorials should show best practices, not just the first thing that works. There should be significant attention paid to how to construct a safe and reliable query. This is not a secondary concern, not when there are automatic hacking tools with a very scary list of features (http://sqlmap.org/) out there for anyone to download.

Microsoft used to be very hand-wavey about security issues and it cost them severely. Now they've tightened all the bolts and Windows is in much better shape because of it.

The PHP community needs to root out these poisonously bad tutorials and eliminate them from search results. How can this be done? By making better tutorials and linking to them more aggressively.

Stop pretending this isn't a problem and start fixing it.

One of the most important things that's about to happen for PHP security, is deprecating the 'mysql' extension[1], which doesn't support prepared statements.

Forcing cheapo web hosts to enable mysqli or PDO will hopefully help a great deal.

I just think they should have added E_DEPRECATED warnings in 5.4 - but I see why they didn't.

[1]: http://news.php.net/php.internals/53799

It's nice that it's generating warnings now, but the best thing for the community would be to completely remove it. It'd be better to answer questions about "Why doesn't my code work?" than "How can I fix my (horribly insecure) app?" where they're not even concerned about the security issues.

PHP 5.5 will produce warnings when using mysql_query. It's a small step forward.

> Can you tell me which language is impervious to SQL vulnerabilities?

That's not the point. The point is that PHP tutorials/books/best practice guidelines repeatedly and consistently do this sort of thing.

Even "PHP: The Good Parts" spent most of the chapter on SQL without mentioning security until the very last part, where they sort of waved their hands at it.

Security is important, and I can't say your concern over it is unfounded. But it seems like its coming from PHPs reputation and not PHP as it stands today.

In the edit to my comment above I touched on this. In short, when you instruct someone on how to do something you put the focus on the task and not the peripheral stuff. You may mention it in passing but to explicitly go over certain things may not be the right thing to do. I can totally see any book or tutorial showing people how to do certain things without mentioning security or kind of glossing over them. That's because you want to make sure a person gets the concept first. Once a person gets how to work with GET/POST or do anything else for that matter, you can then explicitly go over security, mention where to look for vulnerabilities, where to use the security techniques etc.

I learned a touch of Ruby and I'm getting decent with Python right now and pretty much everything I've read either completely skipped security or mentioned it in passing. At a certain point security is introduced and by that point I understood the language enough to know where to apply it in the previous examples from whatever I read. I've also been reading a copy of "Javascript: The Good Parts" and it does much the same thing where you get comfortable with the concepts and security comes later.

I think that because of PHPs history of security problems people are extra sensitive to any PHP code they read online and are almost looking for any way to jump up and say "that's not secure!!". PHP deserves that because of how it used to be but things have and are still changing very much.

Sounds like a documentation problem, not one of the language.

You can shoot yourself in the foot with any programming language. PHP just happens to have one of the shallowest learning curves and greatest availability, so simply by virtue of being everywhere it's responsible for a lot of damage. It doesn't help that a newbie that came up with a working (but dangerous/incorrect/...) solution can then easily start answering other newbies' questions, although that's hardly a PHP-specific thing.

Further - because it's so many people's first programming language, they don't even know to look for information about best practices, let alone go out of their way for it. It takes a seasoned programmer to go out of his/her way to avoid repeating other people's mistakes.

Documentation and Community are a huge part of a languages usefulness. Every language that I consider to be well done has extremely good documentation and a Community that ensures that documentation is up to par.

The argument that community is not relevant to a languages usefulness is simply wrong. PHP suffers from poorer community than other languages. This is improving as the article highlights but it still has a long way to go.

PHP's documentation is some of the best I've encountered (which is quite important, as you have to use it all the time even after ten years because of all the bizarre function names and signatures on the early "core" code).

I completely agree about the community (I'm not sure who your comment is addressing, as I never argued that community is irrelevant, nor did the person to whom I was responding). But on the flip side - having some single pool of up-to-date knowledge is different than a circlejerk, and the "our way or the highway" attitude is very prevalent in some programming communities. Besides being incredibly alienating to newbies, it actively holds back development of new features and discussion of new ideas because these community managers are not trying to solve the same set of problems as the developers using the language/framework.

Yes, it's a damn shame that plenty of PHP example code is from 2006 and still sitting at the top of Google - but by and large, it still works just fine and has accurate information. It may be doing messy stuff like mysql_real_escape_string instead of prepared statements, but the end result is the same.

All of the community and documentation in the world won't stop people from using the tools wrong, and if you take away all the potentially-dangerous tools, you're left with very few things that are actually useful. I'll reiterate my previous point here: something with a low barrier to entry will tend to attract novices, and novices tend to make a lot more mess than seasoned practitioners. If PHP didn't exist and Python or Ruby took its place as the easiest thing to get up and running with, most (no, not all - I've worked with PHP long enough to know which ones are genuinely PHP-specific, and it's not many) of these PHP-hate comments could be run through s/PHP/NEWLANG/g and be completely accurate. Even when you start looking for best practices on a new language you'll encounter a valid counterexample for every single one of them, since it depends on what you're doing.

I looked at "PHP: The Good Parts" and it wasn't what I expected from the name, it just seemed like a standard "Intro to PHP" book, with all the problems that entails.

To be fair, prepared statements have been a solved problem in PHP for a fair long time now, and so it's totally okay to call out the notion of "quickly learning from mistakes" when a subset of that community still doesn't use or encourage them.

You can tar a whole language as bad because some of it's users use it to write bad code, otherwise you'd be talking about all languages.

Is there some magic language out there that cleans all external input for you?

If by "magic" you mean simply disallowing non-structured queries (which is pretty darn easy with a Structured Query Language):

http://en.wikipedia.org/wiki/Language_Integrated_Query

http://www.impredicative.com/ur/

http://pgocaml.forge.ocamlcore.org/

https://github.com/mfp/ocaml-sqlexpr

and that's just off the top of my head.

Also, for instance, the (quite nice) Sequel library in ruby makes this painless

DB["insert into foo (bar, baz, qux) VALUES (?, ?, ?)", bar, baz, qux].insert

And the library handles all the escaping, and even type conversion for you (e.g. Date objects to SQL compatible date strings)