What you do recommend in place of mysql_real_escape_string()?
> -----Original Message-----
> From: Govinda [mailto:govinda.webdnatalk@stripped]
> Sent: Monday, May 14, 2012 7:34 AM
> To: Johan De Meersman
> Cc: mysql@stripped
> Subject: Re: MySQL Community Server 5.1.63 has been released
>
> >>>> Bugs Fixed
> >>>> * Security Fix: Bug #64884 was fixed.
> >>>> * Security Fix: Bug #59387 was fixed.
> >>>
> >>> Anyone want to elaborate on the nature or severity of the security
> >>> problem? Both are private / inaccessible to me.
> >>
> >> Bug #64884 was apparently also applicable to, and fixed in 5.5.24 -
> >> would be very good to know what the vulnerabilities were, so we know
> >> wether or not they apply to us.
>
>
>
> > Not, it seems. Must've been some pretty ugly critters, to get the
> silent treatment.
>
>
>
> Thanks for at least saying this ^^^ . I was wondering too what was the
> nature of those vulnerabilities.
>
>
> Which reminds me... and maybe I am asking something obvious to others
> (?) -
>
> In the PHP circles, as soon as any newbie comes along and shows code
> that makes it evident they are not using prepared statements, or PDO,
> to talk to their MySQL db, then some expert yells at them to do so...
> citing that escaping (i.e. mysql_real_escape_string() ) is "no longer
> valid/secure", etc. There was a famous talk by a security guy whose
> name I forget (Dan ___ ?) that bashed on the whole concept of
> escaping.. pointing out that now with UTF and code points one never
> knows what characters are going to be represented by escaped input, and
> so escape attempts might miss. There is that famous example of that
> charset (I forget, was it a Chinese charset?) where
> mysql_real_escape_string() would allow a code point to be represented
> as a single quote (right? I am not looking in my notes to be sure of
> these details,.. but you guys familiar with all this know very well and
> can correct me?). Anyway my understanding was that a MySQL patch came
> out to address that. True? When security patches come along (like the
> above 5.5.24), I wonder if they might have to do with addressing
> another example of where mysql_real_escape_string() may have failed.
> (?)
>
> 1.) Is anyone *who knows what he is doing* still using
> mysql_real_escape_string()? Ever?
>
> 2.) Can anyone get past the rhetoric/buzz and actually point out with
> authority a way to hack (SQL inject) past mysql_real_escape_string()
> with UTF-8 db/table/collation, from a UTF-8 PHP script? Or is the
> argument against escaping (in the case when using UTF-8) just only
> fear-based?
>
> 3.) Do we understand/expect that the MySQL team makes a point (and
> concerted effort) to keep mysql_real_escape_string() current, so that
> in case any new security holes are found, they are patched? Or have
> even the MySQL devs completely abandoned escaping in favor of prepared
> statements, along with all the buzzy articles and pseudo experts?
>
> I am not attached to escaping, just would like to know what is really
> going on behind the scenes, and also I have legacy code that uses
> escaping (and not prepared statements) and I want to get a sense of its
> shelf life.
>
> More than anything I would like to just shed light on this topic from
> those who KNOW. I have read a lot of rhetoric, but not seen much truly
> authoritative writing.
>
> Thanks,
> -Govinda
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql
