Yeah, the problem is CGI::param() not DBI. I recall many times having to jump through extra hoops because I realized that param() might return more than one value (and I suspect there were times I didn't because I didn't). CGI::param()'s interface isn't "just" a trap for introducing bugs, it is also inconvenient. It is a bad interface, though the badness is somewhat subtle (which actually makes the problem worse, including not just fixing the interface long ago).

The general pattern is that it is fine for something that normally returns several things to, in a scalar context, return just the most interesting aspect of those things. It is a mistake to take something that normally returns just a scalar and create cases where it might return other than just a scalar. And that applies even if the function is documented as "returns all of the values for foo" but a very common case will be that you only expect or want one value "for foo".

Having the name be plural would have made the need to jump through hoops for the common case of just wanting one value more likely to be done. But it still would have been a bad interface.

A better interface would be more like:

sub get_params {
    ....
    return wantarray ? @vals : \@vals;
}

sub get_param {
    return get_params( @_ )->[-1];
}
[download]

But this is far from some fundamental problem with Perl. It is a bad practice to avoid, like can be found when you work with any language to enough depth. I find Perl actually has far fewer of these (and mostly less severe ones) than C or C++, for example.

>

sub get_param {
    return get_params( @_ )->[-1];
}
[download]

If this is a feature request for CGI I'd like to see a setting to raise an exception if multiple values are received where only one value is legally expected.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

Yeah, the problem is CGI::param() not DBI

Hmm, did you ever submit a bug report for that? :)

Speaking of this talk:

bugzilla doesn't even use CGI.pm, it uses Bugzilla::CGI ... if they went that far they could have fixed the API

movable type wasn't doing any argument validation while generating dynamic sql ... can't blame it on CGI

Is CGI.pm's actual interface the best? No, but its been that way for the past 20+ years and its using a common perl feature (context sensitivity) ...

but yeah, context sensitivity is just mental overhead that is easy to avoid

Apart from the urgent need to kick this annoying kid into a pit full of pythons (snakes not hackers¹) I was very surprised about the DBI examples...

Because quote($$;$) has obviously a signature which should force scalar context.

I coded a little example...

use strict;
use warnings;


package DBI;
use Data::Dumper;

sub quote ($$;$) {
    print Dumper \@_;
}

package CGI;

sub param {
    return qw/a b c/;
}

package main;

DBI->quote(CGI->param());

#DBI::quote(CGI->param());
[download]

out

$VAR1 = [
          'DBI',
          'a',
          'b',
          'c'
        ];
[download]

It turns out that signatures are not effective when used as a method, b/c they can't be evaluated at compile time.

OTOH uncommenting the second direct call causes a compilation error.

The documentation of DBI is purely OOP demonstrating method calls...

... so what keeps me puzzled is why the $-signatures where ever inserted.

(It looks like it was originally not meant to be OOP and handling the problem ... but when switching to OOP this use case was forgotten.)

Does anyone have insights if this was addressed now by the maintainers?

PS: YES I'm aware that using placeholders is the state of the art now... though I could imagine someone still using such code in production.

¹) I'm not a sadist...

Could someone please help me find products proven to be vulnerable by using DBI->quote() ?

The only mentioned SQL injection in the talk was

CVE-2014-9057 – MovableType SQL Injection

But I couldn't find any details ... does anyone know the effected code?

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

There is already another "params" method, this had been discussed in the mentioned bugzilla threads.

> The problem is not limited to fat comma either. Consider: @k = qw(foo bar baz); @v = (1,bar(),3); %m = zip @k, @v;

If it comes to "comma" and "list flattening" it's a feature not a problem!

I just used (something similar) again in another post (see (undef,my %hash)= ).

But IMHO implementing => as a "fat" version of comma was misleading, because even experienced Perl hackers expect a 1-to-1 relation, and Perl is supposed to DWIM.

NB Perl6's design has => as "pair-operator" not "fat comma" and the propagation of context into subs has been changed too.

But this is a language design thing which IS NOT a security problem as such.

IMHO HTTP-responses returning more than one value for a singular form-element should be sanitized from the beginning.

I am hereby notifying you of my intention to steal the term thinkosand use freely henceforth. Message ends.

FWIW, I think thinko predates perlmonks/2001 and its not trademarked :)

Spoilsport.  :-P   :-D