Posted: Mon Jan 23, 2006 2:54 am
Chris, thanks for your reply. Some things are cleared up a bit. Others aren't.
I'll try to formulate this as good as I can.
The whole discussion started with the notion:
(note: assumed escaping is meant, not cleansing)
and(2)
However, this exploit is only possible when you set the character set to: default-character-set=GBK
Then, Ilia follows in a post with a similar exploit of mysql_real_escape_string(), also setting the default-character-set=GBK. (done by changing it on a per-connection basis).
Ok. At this point, I am confused. Something which I pointed out in another post in the current thread, to which Chris replies:
1) When I am not changing the character set there is no difference with respect to mysql injection between addslashes and mysql_real_escape_string().
2) When I do change the character set to GBK, addslashes can be bypassed.
3) as can mysql_real_escape_string
2) Mysql_real_escape_string() does escape a couple of characters which addslashes doesn't. This has consequences for the way data is written to log files.
To summerize, although Chris strongly suggests that "The important issue is that mysql_real_escape_string() is more appropriate for escaping data used in a MySQL query", I still cannot see why or when. (assuming I'm not changing the character set)
p.s. 1 - please note that I am just trying really hard to understand this well. I'm not trying to attack anyone. If I misunderstood someone and quoted out of context, please correct me.
p.s. 2 - the whole character encoding thing is something that I will read more about. Untill yesterday I had never heard about GBK before. Let alone change the character encoding in my code.
I'll try to formulate this as good as I can.
The whole discussion started with the notion:
(1)addslashes() and mysql_real_escape_string() are an equal solution to cleansing data before it's inserted in a database
(note: assumed escaping is meant, not cleansing)
and(2)
But then Chris replies:The mysql_real_escape_string function does not protect against SQL injections anymore than addslashes()
, which he explaines on his site. Chris points out that despite the use of addslashes() one can exploit the SQL injection vulnerability.Wrong. .... The important issue is that mysql_real_escape_string() is more appropriate for escaping data used in a MySQL query
However, this exploit is only possible when you set the character set to: default-character-set=GBK
Then, Ilia follows in a post with a similar exploit of mysql_real_escape_string(), also setting the default-character-set=GBK. (done by changing it on a per-connection basis).
Ok. At this point, I am confused. Something which I pointed out in another post in the current thread, to which Chris replies:
So let's get this straight. As far as I understand it now:In fact, even the situation I brought up only applies to multi-byte character sets. If you're not developing an application for an international audience, you won't notice a difference between addslashes() and mysql_real_escape_string(). However, there is a difference, and it does matter to some people
1) When I am not changing the character set there is no difference with respect to mysql injection between addslashes and mysql_real_escape_string().
2) When I do change the character set to GBK, addslashes can be bypassed.
3) as can mysql_real_escape_string
2) Mysql_real_escape_string() does escape a couple of characters which addslashes doesn't. This has consequences for the way data is written to log files.
To summerize, although Chris strongly suggests that "The important issue is that mysql_real_escape_string() is more appropriate for escaping data used in a MySQL query", I still cannot see why or when. (assuming I'm not changing the character set)
p.s. 1 - please note that I am just trying really hard to understand this well. I'm not trying to attack anyone. If I misunderstood someone and quoted out of context, please correct me.
p.s. 2 - the whole character encoding thing is something that I will read more about. Untill yesterday I had never heard about GBK before. Let alone change the character encoding in my code.