Andy Hassall wrote:
>> I had a line:
>> $emailq = $dbh->quote($in{'email'});
> What was it doing? Examples of input and output data?
> It doesn't look like you're passing it a hash anyway, you're just passing
> it a scalar that is an element of a hash.
Er, bad wording. Meant a hash element. :-)
In the above case, $emailq would be NULL. $in{'email'} is already tested at
this point and is definitely not NULL (run through a subroutine that checks
for proper e-mail address syntax).
But:
>> $email = $in{'email'};
>> $emailq = $dbh->quote($email);
- or -
>> $emailq = $dbh->quote("$in{'email'}");
# added " quotes around the hash element.
would both give a correctly 'quoted' variable.
I've now got everything changed to one of those latter two examples, but I'm
mainly wondering why the first example wasn't working. Couldn't find
anything on this in documentation or googling, unless I missed it.
And again, only using MySQL so maybe it's just there? I dunno. Just glad I
caught it before releasing a script in the wild. :-)
> On databases that don't natively support placeholders (e.g. MySQL), DBI
> emulates them, doing the quote()'ing behind the scenes for you, quoting in
> whatever way is appropriate for the database.
Okay, thanks for the tips. Haven't used placeholders before since I only use
MySQL for now, and still fairly new to DBI usage. I'll look into that.
>> a. ensuring numbers are actually numbers
>> b. checking input against maximum allowed lengths for that input
>
> This is a sensible thing to do anyway, particularly on MySQL with its
> habit of silently converting invalid input. If you're using placeholders,
> not checking this shouldn't contribute to SQL injection attacks though.
Okay, sounds good. Though I'll probably leave the checks in anyway.
Redundant checks is never a bad thing with security. Er, unless they're
done wrong. ;-)
Joe
--
Now Playing: Alice Cooper - The Song That Didn't Rhyme
[From The Eyes Of Alice Cooper (2003)] (2:05/3:17)
Powered by XMMS and SuSE Linux 8.2 Pro
