On 1/21/2010 3:53 PM, Kynn Jones wrote:
> On Tue, Jan 19, 2010 at 4:49 PM, Andy Colson <andy@squeakycode.net
> <mailto:andy@squeakycode.net>> wrote:
>
> On 1/19/2010 3:39 PM, Andy Colson wrote:
>
> On 1/19/2010 3:23 PM, Kynn Jones wrote:
>
> I have a Perl CGI script (using DBD::Pg) that interfaces with a
> server-side Pg database. I'm looking for general
> guidelines/tools/strategies that will help me guard against SQL
> injection attacks.
>
> Any pointers/suggestions would be much appreciated.
>
> ~K
>
>
> prepare your queries:
>
> my $q = $db->prepare('select something from table where key = $1');
> $q->execute(42);
>
> and..
> $db->do('update table set field = $1 where key = $2', undef,
> 'key', 42);
>
> (*guessed at the do(). I think there is an undef in there, or
> something*)
>
> -Andy
>
>
> Also, add to that, in general, use Taint Mode. Perl wont trust data
> until its been sanitized... and neither should you.
>
>
>
>
> I can't get this to work in any way. At the end of this email, I post a
> complete script that runs fine under Taint Mode, even though it DBI is
> being passed tainted variables in various places.
>
> Do I need to do anything else to force a failure with tainted data?
>
> Demo script below; to run it, it requires four command-line arguments:
> the name of a database, the name of a table in that database, the name
> of an integer-type column in that table, and some integer. E.g., a run
> may look like this:
True, by default DBI ignores taint, you'll need to enable it:
my $dbh = DBI->connect($connection_string,
"kynn", undef,
+{
Taint => 1,
RaiseError => 1,
PrintError => 0,
PrintWarn => 0,
});
-Andy
