Re: Re: Secure data management

>> > 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 Paul, 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 -Govinda