> There is more to SQL injection than getting the quoting correct. In my
> understanding, prepared statements handles the other problems associated
> with queries and SQL injection beyond just quoting. Here's a good
> tutorial on how this works:
> http://www.youtube.com/watch?v=bORZlmyDw0s


thanks.. I always appreciate more input as I cement my understanding of all the 
various things to be aware of.

But here my question was coming from a slightly different angle than you seemed 
to address.

You showed in that youtube video that type casting (if I said that right) might 
be needed instead of mysql_real_escape_string() (in case the questionable input 
is numeric instead of a string), but I was asking (essentially), "when is 
mysql_real_escape_string() not enough for escaping *strings*?.. or, "when do we 
have a case where one would normally trust escaping a user-input *string* by 
using mysql_real_escape_string(), but where a clever hacker can get around?... 
by, say, using some obscure multi-byte char?"  - perhaps the way Chris Shiflett 
shows how to hack past addslashes when using certain multi-byte character sets 
in his article [1].

Again (for anyone following this thread), I understand that prepared statements 
just remove so much of the headache.. but in case that is not available in some 
setup, then when does mysql_real_escape_string() fail for escaping stings 
(assuming the db/charset is UTF-8)?

[1] http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to