>>>> 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
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
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
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.