Warning about the article "SQL Injection" in current "PHP Magazin"

The article - written by one Patrick Lobacher who has a couple other publications under his belt - is titled "Advanced techniques for the popular hacking technique" and I came to believe that there is actually going to be something advanced. However, the first half page reiterates about "OR 1=1" injections and intruces some new, trendy terminology (whew, "ByPass-Login", neat-o!).

An important quote from that part of the article is:

[..] most examples in this article are based on the MySQL-SELECT statement [..]

so I'd say it's safe to assume the author tested under MySQL and MySQL only. FWIW, there's no mention of DBMS other than MySQL and no mention of OSes other than Unix and consorts in the whole article.

Then, we start doing UNION selects. This kind of SQL injection is not new, neither to PHP beginners who have ever heard of SQL injecition at all, nor to people who actually have a real clue about security. But hey, this is not Phrack, so let's assume that halfway intermediate readers are the target audience.

The UNION SELECT statements are OK so far, including the odd CONCAT trick. Then, the author moves on to "manipulation of data" and here, things get funny. Who spots the problem with this statement:

SELECT headline, textcomplete FROM newsarticle WHERE id=37; UPDATE user SET user_password='neuesPasswort' WHERE user_id=7

(I marked the part that is supposed to be injected via GET in bold).

Let's try this out:

<?php $res = mysql_query("SELECT 'foo'; SELECT 'bar'"); ?>
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '; SELECT 'bar'' at line 1


Meh. Dudes, there is no multi query capability in PHP's mysql_query! This example does not only profoundly demonstrate that the author is unaware of how the PHP MySQL API works, but also that he did not actually TEST his "findings". This is, from a journalistic standpoint, an absolute faux pas. Of course, there is mysqli_multi_query, but who uses that? I never did.

That kinda got me ticking and I proceeded to check out more examples. This one for example:

http://www.meinserver.de/news.php?id=37 UNION SELECT 1,load_file('/etc/passwd')#

As a normally authorized user, this yields the following:
mysql> select 1,LOAD_FILE("/etc/passwd");
+---+--------------------------+
| 1 | LOAD_FILE("/etc/passwd") |
+---+--------------------------+
| 1 | NULL |
+---+--------------------------+
1 row in set (0.00 sec)
However, this example works if you are the "root" MySQL user (or, for that matter, any user with the FILE privilege, which is to my knowledge not used in web applications at all). I do by no means underestimate the global potential for stupidity, but who in their right mind would use the "root" user for MySQL/PHP applications? Every application I know of creates a dedicated user in the installation routine, and no hosting provider would ever give you root on a shared database server. So, the author obviously tested his article as the "root" super user. There is no mention of that restriction anywhere in the article.
The next section suffers from the same problem: you can't write to a file if you don't have the FILE privilege. As that privilege is not handed out easily, it is very, very, VERY far-fetched to assume that it will be present for a web application user. Well, same mistake made twice, so it's not a simple oversight.

However, another mistake in the same section shows that the author does not only have no clue about SQL injection, but neither about toolsets used by attackers. He claims that, and I quote again,

These PHP files [he means web-based shells] allow for convenient access to almost any area on the server, using all known security holes. One of these web shells is the often seen r57shell.

Dude. r57shell does not exploit anything at all. It is a web-based shell and toolkit that allows attackers (mostly them, although you could even imagine legitimate uses) to gather information and perform often-perfomed tasks like FTP upload, file download and manipulation etc. directly from within the exploited application. Yes, exploited like "in the past". A working exploit is necessary to even be able to run r57shell. It does not, I repeat, not, do anything illegitimate, it only uses normal PHP functions. If someone thinks that r57shell exploits security holes, they could not be more mistaken.

By now, I'm rather pissed off at the article (as you might notice). There's another funny paragraph about DoS, which (apart from the hashing function) is pretty much 100% what we write in our book, but not really new or anything. The next paragraphs about white and black box testing are pretty much illegible. I think the author claims that for white box testing, you should use Google Code to "audit" an application's source code. What about downloading a copy (white box, remember? Source code available!) and greping it? Ah, I know. It doesn't make for nice pictures of a Google Code search subtitled "over 6000 results for potentially vulnerable applications". Gah. Is this the Daily Mirror? I think you lost your headline writer.

Telling us that adding a single quote to a URL parameter is "error based SQL injection" is so silly I won't even mention it. Oh, I just did, well... it's silly.
Regarding the next paragraph, "Blind SQL Injection", there's only a couple of mistakes in there, and oversights too. What, for example, happens if you type the following URL:

http://www.meinserver.de/news.php?id=30+7

Yeah. We have a string variable $_GET['id'] that is "30 7". Why? Because in GET requests, the plus sign is not a plus sign, but masks the space. Maybe someone should have read up about HTTP? Or actually tried the example?

Then, out of the blue, the benchmark() function is used, without further explanation, to check for a valid user. and iterative password detection. These two queries are the only thing that I find in any way "advanced" - and yet, they are not explained at all, just thrown on the page and that's it. That smells to me like copy&paste from another source. I quickly scanned through the SQL Injection Cheat Sheet which is even referenced as a source, and shazam, the two BENCHMARK examples are in there. Exactly (!) the same ones, including all the table and column names as well as the exact count of benchmark runs. Hilarious, isn't it.

The best point is the last section, "how to avoid SQL injection". First tip: "Always program cleanly." Good idea. Then, at least mysql_real_escape_string() and typecasting is mentioned, but that's about it. About 1/20 or so of the article went into these tips. Prepared statements? Nooooo.

Actually, that kinda rings another bell. Where is mysqli? After all, it has been around for the last, what, gazillion years? There is no mention in the listings, none in the examples - I presume the author does not know of that extension's existance. But hey, it's only 2008...

To sum things up, this article easily ranks among the top 5 worst security articles I have ever had the "pleasure" of reading. It is incoherent, does not live up to the teaser, contains numerous and severe errors and generally shows no sign that the author had anything other than a cheap buck on his mind when he slapped it into his MacBook.

Seeing that the author proudly presents the seal of the "German Association of specialized journalists" on his home page, I would really encourage him to stick to other specializations than security. It pains me to see people abuse a topic I care about like this, telling unaware newbie developers stuff that is simply not true. It also pains me that the number one PHP publication in Germany signs articles like that one off and advertises a "PHP security camp" two pages before that article - an event that has a lot of REAL security people and is actually co-hosted by PHP Magazin.

Quick Update: Björn Schotte has responded in this article. I have since then disabled my RBL Plug-in, thanks for pointing that problem out, Björn. More later. :)