|
|
Posted by Marek Kilimajer on 05/14/05 15:03
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/
Navigation:
[Reply to this message]
|