On Fri, May 13, 2005 12:51 am, Marek Kilimajer said:
Richard Lynch wrote:
On Thu, May 12, 2005 4:43 pm, Chris Shiflett said:
From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack.
Under the following pre-conditions: 1. C Locale / English in MySQL data 2. No intention to ever switch natural language, nor database.
is there any real benefit to spending man hours I really can't afford for legacy code to switch from Magic Quotes to mysql_real_escape_string -- and make no mistake, it would be a TON of man hours.
It will take less than five minutes to write a recursive function that will stripslashes() all incoming variables and use mysql_real_escape_string() instead.
Except that for integer data, I just type-cast to (int) and check the range, but for some string data, which should not have had any characters that need escaping, I'm doing a regex, and for the string data where characters that needed escaping, I'm already doing stripslashes(), then a regex, then an addslashes(), so applying stripslashes() to all incoming data will break all of those last ones pretty badly.
Are we all on the same page now? :-)
If this is how your application works now then it's really only search and replace s/addslashes/mysql_real_escape_string/
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
