NYCPHP Meetup

[Dan Cech]

David Krings wrote:
> Hi,
> 
>     my guess is that some of the characters escaped using the mysql 
> escaping cannot be reasonably expected to come in from user input. 
> Mysql_real_escape_string escapes all these:
> \x00, \n, \r, \, ', " and \x1a
>     but I can't think of any way on how to get \x1a as user input 
> (assuming that this is the hex value for an ASCII character). Even NULL 
> is difficult, but not impossible. I guess that the "ultmately 
> unecessary" looks at it from a viewpoint of what is possible assuming 
> the user is the idiot and not the developer. It consumes a trip to the 
> database engine and back, whereas addslashes doesn't. I don't know, my 
> arguments are a bit thin and it may really just like that: "ultimately 
> unecessary" as long as the string was addslashed.

What you're failing to consider here is the character set of the active
mysql connection.  Correct me if I'm wrong, but it is my understanding
that mysql_real_escape_string does not incur an extra trip to the
database, the escaping still occurs within php, but it takes into
account the character set of the active connection.

This may not seem that important right now, but when you find yourself
wanting/needing to switch to utf8 you'll be glad you used mysql_real_escape.

As for how strange characters might get into input, assuming that it
won't happen is just plain bad practice.  Of course the enterprising
hacker will find a way to inject these characters, and addslashes will fail.

When dealing with user input, always use the very best tools you have
available to you, because the one corner you cut will be the chink in
your application's armor.

Dan

> 
>     David K.
> 
> Cliff Hirsch wrote:
>> I just read the same thing in Cal's book and was going to ask the group
>> about this. While prepared statements sound nice in theory, there are
>> many of us that still hack together "old-fashioned" queries. And what
>> does "ultimately unnecessary" mean anyway? Consumes more mips than its
>> worth?