in reply to Re^4: Removing malicious HTML entities (now with more questions!)
in thread Removing malicious HTML entities (now with more questions!)

I would always use placeholders simply for the speed increase they offer, but does the use of them imply the placeholder content is, for want of a better phrase, SQL-escaped for the actual DB in use?

My scan of the documentation didn't find that information for placeholders but seemed to imply that $db->quote() might. I would like to know for sure if placeholders also perform this function.

Replies are listed 'Best First'.
Re^6: Removing malicious HTML entities (now with more questions!)
by techcode (Hermit) on Aug 27, 2008 at 12:07 UTC
    Yes it does wrap '' around them. Which can lead to problems when you say want to call a function such as NOW() - because then you don't want it quoted.

    Have you tried freelancing? Check out Scriptlance - I work there. For more info about Scriptlance and freelancing in general check out my home node.
      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.
        Ugh I had to write so much of code that resembles what you have there - that at the end I wrote my own little DB "abstraction" (more like SQL generator and executer) to re-factor all that. It generates SQL by using placeholder for everything (values) and based on fields available in data/form and table. So I ended up with something like:
        $DB->insert_record( table => 'mytable', data => $form, ); # But if you want timestamp => NOW() it should not be used as # placeholder so I added another parameter marking which fields # should be included as they are ... Of course this particular # example would better been done by setting default value of # timestamp field to NOW() and sending nothing here.... $form->{timestamp} ||= 'NOW()'; $DB->insert_record( table => 'mytable', data => $form, as_is_fields => $form->{timestamp} eq 'NOW()' ? [qw/timestamp/] : [ +], );
        Now days I just pass around hashrefs from CGI to my DB-thing (through HTML::Entity and Data::FormValidator first), and from DB-thing to TemplateToolkit on output. And just take care to use same field names in all of those - so that DB-thing could do it's magic.

        Have you tried freelancing/outsourcing? Check out Scriptlance - I work there since 2003. For more info about Scriptlance and freelancing in general check out my home node.