What you do recommend in place of mysql_real_escape_string()? > -----Original Message----- > From: Govinda [mailto:[email protected]] > Sent: Monday, May 14, 2012 7:34 AM > To: Johan De Meersman > Cc: [email protected] > 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
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
