Re: MySql injections (related question)

Richard Lynch wrote:

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/