Posted by AnrDaemon on 11/06/07 11:20

Greetings, NoDude.
In reply to Your message dated Tuesday, November 6, 2007, 12:25:08,

>> > PHP doesn't know everything about the MySQL server, so escaping string can
>> > be tricky business (especially with 'broken' Unicode, there's a very slim
>> > possibility a quote will appear where there was none). Prepared statements
>> > free you from that headache.
>>
>> Sorry, but... what mysql_real_escape_string function does then?

> the *_real_escape_string family get the encoding they're supposed to
> escape from mysql while connecting, if you happen to set mysql to
> another encoding (and in some edge cases just in php) you might not
> get the string you expected in mysql. That's what Wasmus was talking
> about, when he mentioned there's a chance of a quote appearing where
> you didn't expect it.

> A user might put a character that's supposed to be a in cp1251, but
> is a ' in some Uganda encoding. You happen to be in uganda and you
> happen to not use true UTF, so you do some encoding switching. Worst
> case scenario - maybe a table will be dropped. Hackers on the other
> hand try huge amounts of possible sql injections. If there's a weak
> spot, they're bound to find it sooner or later.

> If you're keen on using the mysql extension, make suer everything you
> do is true unicode, but there's still the chance you happen to forget
> to escape something, somewhere, somethime.

Example? I can't understand what You talking about.

If I working with *_real_escape_string, it is for sure escaping characters
which would cause damage to SQL statement in current SQL encoding.
Not related to encoding PHP uses. It is just thing from different world.

So then, if someone supplied a string in any encoding, it is only byte array
while passed to escaping function.


--
Sincerely Yours, AnrDaemon <anrdaemon@freemail.ru>

[Back to original message]