It's hard to imagine a sensible application where an (untrusted) input data value for an SQL operation would properly include a call to an SQL-internal function. Something like "NOW()" would either be an invariant (hard-coded) piece of the SQL statement, or else would be something that is assembled and added to the SQL (or not) based on the presence/absence/value of some input parameter(s).
In the latter case, the value(s) of the parameter(s) would not go directly into the SQL string, but would only be tested to figure out what function call(s), if any, should be added (as literals) to the SQL. Example:
my @flds = ( qw/foo bar status/ );
my @vals = @param{@flds};
my $valstr = join( ",", ("?") x @flds );
if ( $param{timestamp} ) {
push @flds, "timestamp";
$valstr .= ",NOW()";
}
my $sql = "insert into mytable (" . join( ",", @flds ) . ") values ($v
+alstr)";
my $sth = $dbh->prepare( $sql );
$sth->execute( @vals );
There are other ways to handle this that would suffice (e.g. careful regex matches on untrusted values in order to include things in the SQL statement), but as a rule, the application should have a limited inventory of function calls that it supports/allows.
|