Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Improving the security of SQL::Interp

by markjugg (Curate)
on Jan 06, 2010 at 20:08 UTC ( #815974=perlquestion: print w/replies, xml ) Need Help??
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 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?

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)

    #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.

Re: Improving the security of SQL::Interp
by markjugg (Curate) on May 03, 2011 at 17:31 UTC

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://815974]
Front-paged by zwon
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (10)
As of 2017-04-24 21:13 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (447 votes). Check out past polls.