Prevention of SQL injection in PHP
11–15 of 15 posts
Re: Prevention of SQL injection in PHP
#12Hi, 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 o…
Pros: 1. Save on query parsing 2. Save on data conversion and copying 3. Avoid SQL Injection 4. Save memory on handling blobs
There are also a number of cons. Check out the article before you make this jump.
Re: Prevention of SQL injection in PHP
#13Yikes, 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), m…
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.
Re: Prevention of SQL injection in PHP
#14Yikes, 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
#15@ 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 ;)