thanks for the tip!
I think mysql_real_escape_string() is safe enough.
Thanks for the link MrOrange that is a great read and I wish I had read it years ago.
Thanks for pointing the stuffs. Just came directly here from google search. I too have a similar problem 
The post by triexa claims the addslashes() function will be removed in php6.
does that also mean magic_quotes_gpc will disappear since that auto-runs addslashes() on all POST/GET input.
another thing it seems that not all database specific APIs have a function to add slashes to the string.
besides, I am looking for a way to code as database independant as possible,
so I am not really happy with using a database specific slashing function.
and if I understand this exploit problem correctly, as long as I ensure my data is valid UTF-8 encoded, this exploit could not be used.
magic_quotes_gpc is already disabled by default, and it will be removed completely from PHP 6 an onwards. addslashes will still be there, so you can run it manually, if you want.
You should use PDO and prepared statements. They work across different database systems/sql dialects and (more importantly) they are completely safe against injection type attacks.
The thing is, data usually comes from users, and therefore you have no guarantee as to their contents.
I can verify the encoding of the string with mb_check_encoding()
I wish to verify the encoding, not only for security reasons but also to be sure the data is valid, as in, will be displayed correctly.
OK - That’s probably not a bad idea, but security-wise prepared statements are completely resistant to any kind of sql-injection attack. This is because with bound parameters, the data and the query are transmitted separately and the data is never interpreted by the database engine.
All you guys rock and its a very good learning experience for newbies like me.
Great!!! really great!!! SPAM about MATH only AFTER I FAILED FOR MY MATH EXAM!!!
Thank You for your great tips! I my opinion too mysql_real_escape_string() is safe enough.
… and to think all I did was abandon the mySQL_ functions completely and switch to PDO with prepare/execute.
I agree - mysql_real_escape_string is completely unnecessary if you write your SQL calls properly. Another dinosaur to remove from your toolbox.
You don’t even need to switch to PDO either since the mysqli_ functions support prepare statements (either procedural or object oriented) without the need for anything else.
True, but I’m not wild about having the mySQL connection global in scope… another reason to abandon the procedural and if the connection is needed in other functions, pass the PDO object by reference.
The mysqli_* functions require neither global connection resources nor procedural syntax.
What has that got to do with anything - the only difference between the mysql_ and mysqli_ connections if you use procedural code is that whether the database connection comes before or after the query in the parameter list.
If you use the OO version of mysqli_ then you don’t need to specify the connection as it is stored within the SQL object you create when you open the database connection.
Whichever way you access the database the scope of the connection depends entirely on when you do the call to connect and is exactly the same for bot mysql_ and mysqli_
The only difference is that mysqli_ supports the prepare statement without the need for any add-ons such as PDO.
As such using mysqli_ is the cleaner and potentially more secure alternative.