On 2009-02-03 10:06:48 -0800, Douglas Wilson wrote: > On Tue, Feb 3, 2009 at 5:47 AM, Deviloper <devilo...@slived.net> wrote: > > But some bad guy could showed up and force the poor developer not to use > > perl-vars in SQL-Statements for security reasons. > > > > Is ist possible to use tablenames like normal bind-variables? > > Is there a better way to solve this problem? > > Using perl vars is ok as long as you untaint them (you are using > taint checking in programs that use untrusted user input, right?).
I think this could be understood differently than you probably meant it.
Perl variables are not generally unsafe, and untainting them doesn't
make them magically safe.
The tainting mechanism in perl assumes that any input from the user is
unsafe and taints it. By untainting the variable you just tell perl "I
have checked that this value is safe". Whether the check was sufficient
to ensure safety perl has no way to tell - it has to trust the
programmer.
In the context of this thread you probably want to give the user access
to certain tables ('jan_sales', 'feb_sales', ..., 'dec_sales') but not
to others (e.g., 'employees').
Depending on the input, you can check the input:
unless ($month =~ /^(jan|feb|...|dec)$/) {
die;
}
$month = $1;
$sth = $dbh->prepare("select * from ${month}_sales ...");
or maybe you don't need to untaint at all because the input is only used
for lookup:
my %quarters = {
q1 = ['jan', 'feb, 'mar'],
...
q4 = ['oct', 'nov, 'dec'],
};
my @months = @{ $quarters{$quarter} };
unless (@months) {
die
}
for my $month (@months) {
$sth = $dbh->prepare("select * from ${month}_sales ...");
}
Here $month is never tainted because it can get only values from your
program, not from the user. So it is safe to use.
hp
--
_ | Peter J. Holzer | Am Anfang war der Bug und der
|_|_) | Sysadmin WSR | Verantwortliche sprach:
| | | h...@wsr.ac.at | Es werde ein Testcase.
__/ | http://www.hjp.at/ | -- Clemens Zauner in dcii
pgpkqcWcegSgV.pgp
Description: PGP signature
