In article <[EMAIL PROTECTED]>,
"B. van Ouwerkerk" <[EMAIL PROTECTED]> writes:
> I've been reading this discussion and I asked myself whether you guys
> remove/replace unwanted chars from strings you get from the web or
> not..
The problem is not limited to strings you get from the web. Those
st
In article <[EMAIL PROTECTED]>,
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> 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.
Perha
Hi folks
Very instructive thread. Thanks to everyone for the input, and
especial thanks to Lincoln Yeoh for his detailed explanation of his
approach: a standout post!
Sorry for the silence - it's not that I'm unappreciative, just that
I've been away from my desk.
Tom Lane wrote:
> I think you m
update tablea set a=10-$inputstring where key=1;
Add parenthesis:
update tablea set a=10-($inputstring) where key=1;
Thus you get :
update tablea set a=10-(-1) where key=1;
instead of :
update tablea set a=10--1 where key=1;
You'd have a problem because -- is the Commen
Python has an interface like this :
params = { 'mystrfield': 'hello', 'myintfield': 5 }
cursor.execute( "SELECT myfield FROM mytable WHERE
mystrfield=%(foo)s AND myintfield=%(bar)d;" , params )
It has the following advantages :
- separation of sql from data
- named parameters
Geoff Caplan wrote:
Hi folks
Seems we have two schools of thought:
1) The validation/escaping approach, supported by Bill and Jim
2) The "don't mix data with code" approach supported by Peter and
Greg.
As I learn more about the issues, I am increasingly veering towards
the second approach.
Now I a
Jim Seymour wrote:
Bill Moran <[EMAIL PROTECTED]> wrote:
[snip]
I agree with Bill. Years ago (more years than I care to recall) I read
a book on structured systems design (IIRC) that advised one should
condition/convert data as early as possible in the process, throughout
the design. Amongst the
Magnus,
Your posting arrived just after I posted my attempt at a summary...
With the help of the list, I had already got to the stage that
parameterised queries are the way to go. Your post helps confirm
that.
Now I need to understand the implementation details. Clearly, one
option is the PREPAR
Hi folks
Seems we have two schools of thought:
1) The validation/escaping approach, supported by Bill and Jim
2) The "don't mix data with code" approach supported by Peter and
Greg.
As I learn more about the issues, I am increasingly veering towards
the second approach.
Obviously, proper valid
> Most of the online literature is on MS SQL Server. There, the
> consensus seems to be that the range of potential attacks is
> so wide that attempting to spot attack signatures in posted
> data is a doomed enterprise, and that the safest general
> approach for any dynamically built query is t
Bill Moran wrote:
>
>
>Simply put:
>1) If the untrusted value is a string, using a proper escape sequence
should
> make it safe.
>
>
in pgsql (and mysql) you can escape almost everything.
update table set a = '5' is corrent, even is column a is integer type.
You can't escape the null value.
Bill Moran <[EMAIL PROTECTED]> writes:
> Geoff Caplan <[EMAIL PROTECTED]> wrote:
>
> > Hi folks,
> >
> > I'm new to Postgres and trying to get up to speed on the security
> > issues. There seems to be remarkably little Postgres specific stuff on
> > preventing SQL injection attacks.
> >
> > Mo
Bill Moran <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> Simply put:
> 1) If the untrusted value is a string, using a proper escape sequence should
>make it safe.
> 2) If the untrusted value is not a string, then it should be tested for
>proper value (i.e. if it should be a number, it should be
Geoff Caplan <[EMAIL PROTECTED]> wrote:
> BM> To protect yourself from SQL injections, just pass all your data through
> BM> PQescapeString()
>
> I'm no expert, but the papers I have been reading suggest that the
> usual hygene advice such as don't display DB error messages and escape
> unsafe str
Hi folks,
Peter Eisentraut wrote:
PE> If you use prepared statements (the details of which vary by >>
PE> programming language), you should be quite safe.
Peter - thanks for the suggestion. You are right: a poorly designed
function might simply concatenate the injected code - I hadn't really
tho
Geoff Caplan <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> I'm new to Postgres and trying to get up to speed on the security
> issues. There seems to be remarkably little Postgres specific stuff on
> preventing SQL injection attacks.
>
> Most of the online literature is on MS SQL Server. There, the
Geoff Caplan wrote:
> I'm new to Postgres and trying to get up to speed on the security
> issues. There seems to be remarkably little Postgres specific stuff
> on preventing SQL injection attacks.
If you use prepared statements (the details of which vary by programming
language), you should be qu
Hi folks,
I'm new to Postgres and trying to get up to speed on the security
issues. There seems to be remarkably little Postgres specific stuff on
preventing SQL injection attacks.
Most of the online literature is on MS SQL Server. There, the
consensus seems to be that the range of potential atta
18 matches
Mail list logo
