Yikes, that's a lot of bad advice for one article. 3 out of 4 methods it recommends for preventing SQL injection should be avoided and it doesn't even mention prepared statements at all.
While we're at it: it also fails to understand the difference between addslashes() and mysql_escape_string(). (It's not just a matter of whether you're assigning the result to a variable or not!)
Techincally, I don't have to do mysql_real_escape_string on the $user_id variable, since it is not based on user input and sprintf will automatically convert it to 0 if it isn't a number already (and there are no user_ids that equal 0 or 1 in this particular table)
(Before someone asks, all the passwords are salted and encrypted using SHA-256. Although, now that I think about it, they are in a binary format, which makes me wonder if I should use %b instead of %s... and since its in binary format already, I really don't need mysql_real_escape_string for the password either. Ugh )
It's got real prepared statements (or a reasonable facsimile thereof for databases that don't support them), and it lets you iterate directly over result sets. All sorts of handy stuff.
They should also be suggesting straight up data validation before sticking anything in the db. No reason to let things get that far if you're expecting a number and they give you garbage.
As the blog comments are hinting, this is a terrible way to achieve "prevention of SQL injection". One missed addslashes() and you're toast. The real answer is to use prepared queries through mysqli, PDO, ADODB, or similar.
The developer who's writing this apparently hasn't ever tried SQL injection, though. If they had, they'd know that trying to tack on a second query with a semicolon doesn't work with PHP's mysql functions. The only real way to understand security flaws of this sort is to try exploiting them yourself.
Hi, I'm still a little confused about the advantage of prepared statements. No explanation I've seen so far has actually explained why they are good, but my thinking was that the developer does not have to remember all of the dangerous characters to escape because the prepared statement stuff do that for you. But now I'm reading here http://dev.mysql.com/tech-resources/articles/4.1/prepared-st... that the advantage of paramterization is separating the SQL logic from the data supplied. Why would that matter? You can still supply data such as ' OR 'x'='x
One of those solutions still leaves you vulnerable to other SQL injection methods. While it technically prevents those false logins, you're still wide open to other forms of SQL injection. I'm not sure why something like that would even be mentioned.
