Skip site navigation (1) Skip section navigation (2)

Re: Sql injection attacks

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Sql injection attacks
Date: 2004-07-28 09:23:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
At 11:13 PM 7/26/2004, Tom Lane wrote:

>I think you misunderstood.  Escaping is perfectly safe (given a correct
>escaping function) if it's used on *every* untrustworthy input string.
>The argument for the "keep data separate from code" approach is
>essentially just that it's easier to be sure you haven't forgotten
>anyplace where you need to escape.

Just curious on what are the correct/official ways for dealing with the 
following scenarios:

1) Input string contains % and _ and would be used in a LIKE query that 
should not have user controllable wildcards.

2) Input string are numbers which can hold negative and positive values and 
could potentially be used in the following query:

update tablea set a=10-$inputstring where key=1;

When I tested at least one version of DBD::Pg doesn't appear to escape the 
inputstring when it's a number.
$SQL="update tablea set a=10-? where key=1";
And $SQL is used in a prepared statement with $inputstring as a parameter.

I found that when $inputstring contained a negative number, all rows in 
tablea are set to the same value.

3) Postgresql queries with select .... from ...  where ... LIMIT $inputstring

Postgresql 7.3.4 doesn't like LIMIT '1'
Nor does it like LIMIT '1'::integer

Haven't checked OFFSET.

(sorry- I downgraded to 7.3.4 and haven't upgraded).


In response to


pgsql-general by date

Next:From: R.WelzDate: 2004-07-28 09:36:47
Subject: Discussion wanted: 'Trigger on Delete' cascade.
Previous:From: raptor@tvskat.netDate: 2004-07-28 09:13:48
Subject: pgadmin III ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group