markjugg has asked for the wisdom of the Perl Monks concerning the following question:

SQL::Interp is an excellent tool to help build SQL. It can be especially pleasant to use from DBIx::Simple. Combining the two, you can do this: 
 $result = $db->iquery("SELECT * FROM foo WHERE a = ",\$b)
It's easy to read, and $b will automatically be translated into a bind variable. My concern is that on a number of occasions I have seen well meaning programmers do this instead: 
 $result = $db->iquery("SELECT * FROM foo WHERE a = ",$b)
The difference is the backslash before the $b. The rub is that the code produces the same result either way, but the second format has possibly introduced an opportunity for a SQL injection attack. What suggestions do you have for how SQL::Interp might detect such cases, so that it can warn or die? Here are some brainstorms I've thought of, possibly activated only when a "strict mode" is enabled.
  1. Scalars are no longer allowed at all. Instead, you would use something like: "sql('SELECT * from foo WHERE a = '),\$b"
  2. Assume any two strings in a row is a mistake...you could always concatenate them instead.
  3. Parse the SQL sufficiently to understand where bind variables *should* be and then make sure they are used there.
Each option has its drawbacks, but does one stand out to you as being better? What other ideas can you think of to addres s this?

Mark Stosberg

Replies are listed 'Best First'.
Re: Improving the security of SQL::Interp
by Porculus (Hermit) on Jan 06, 2010 at 22:10 UTC

    Of your three, #2 looks best to me. It's a decent heuristic.

    #3 is, I think, actually impossible in general. Consider:

    my $v1 = 'field3';
my $v2 = 'value';
sql_interp('SELECT * FROM table WHERE field1 = ', $v1, ' AND field2 = 
+', $v2)

    [download]

    #3 would presumably make this be equivalent to field1 = 'field3' AND field2 = 'value', but the programmer might well have intended it to be field1 = field3 AND field2 = 'value', at which point the DWIMmery would merely have resulted in a perplexing bug. There's no way to determine which of the two was intended (let alone the other possible permutations), so it's better just to require the programmer to be explicit.

[reply]
[d/l]
[select]
Re: Improving the security of SQL::Interp
by markjugg (Curate) on May 03, 2011 at 17:31 UTC
[reply]

Back to Seekers of Perl Wisdom