Prevention of SQL injection in PHP
dev.digi-corp.com
Prevention of SQL injection in PHP
1–10 of 15 posts
Re: Prevention of SQL injection in PHP
#2Yikes, 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.
Re: Prevention of SQL injection in PHP
#3As 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.
Re: Prevention of SQL injection in PHP
#4Yikes, 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!)
Re: Prevention of SQL injection in PHP
#5addslashes is NOT an appropriate way to prevent SQL injection attacks. Chris Shiflett explained the addslashes vulnerability years ago:
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-re...
Re: Prevention of SQL injection in PHP
#6Yikes, 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.
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.
Re: Prevention of SQL injection in PHP
#7Yikes, 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.
Like you mention, I cannot understand how a problem like this that has been solved gets such a bad solution.
For those, like me, who are slaves to mysql for one reason or another, this is what I do.
1) mysql_real_escape_string 2) sprintf
I usually mix the two. Here's an example.
$format = "UPDATE `Users` SET `user_password` = '%s' WHERE `user_id` = %d";
$query = sprintf($format, mysql_real_escape_string($password), mysql_real_escape_string($user_id) );
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 )
Re: Prevention of SQL injection in PHP
#8Yikes, 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!)
While you're still at it: get rid of the quotes entirely, just htmlentities( ) where appropriate.
Re: Prevention of SQL injection in PHP
#9Hi, 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
Re: Prevention of SQL injection in PHP
#10@ the OP you might want to go ahead and update your blog -- potential clients googling your company might stumble across it and run away in fear ;)