From: Denis <sqllist@coralindia.com>
To: pgsql-sql@postgresql.org
Subject: Re: how to preserve \n in select statement
Date: Mon, 22 Dec 2003 15:07:25 +0530
Message-ID: <004c01c3c86f$389c5380$0f32a8c0@denisnew> (raw)
References: <BAY9-F42t0CI76rOJhK00098f93@hotmail.com>
<200312220904.11730.dev@archonet.com>
Hi Richard..
If your users are required to fire only SELECT and no DML, you can do the
following:
BEGIN;
execute the statements given by user
ROLLBACK;
This will not affect your SELECT and also if any malicious user gives DELETE
statement, that will not have any impact too..
HTH
Thanx
Denis
----- Original Message -----
From: "Richard Huxton" <dev@archonet.com>
To: "Matt Van Mater" <nutter_@hotmail.com>; <tgl@sss.pgh.pa.us>
Cc: <pgsql-sql@postgresql.org>
Sent: Monday, December 22, 2003 2:34 PM
Subject: Re: [SQL] how to preserve \n in select statement
> On Saturday 20 December 2003 17:58, Matt Van Mater wrote:
> >
> > I readily admit that I didn't read much into it, but I think you are
> > mistaken. If you look at the following links you will see that
postgresql
> > definitely had a vulnerability that allowed sql injection through the
use
> > of escape characters. I was simply saying that this behavior might be a
> > way of preventing that from happening again.
> > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0802
> > http://cert.uni-stuttgart.de/doc/postgresql/escape/
>
> Ah - this "vulnerability" is still there - and, in fact is in every
database
> ever produced. The issue is that applications using untrusted data to
build a
> query string can be duped by a malicious user.
>
> So - say you have a query template:
> SELECT * FROM recent_news WHERE topic='?'
>
> If a malicious user supplies the string: '; DELETE FROM user_logins;
SELECT '
> then you will have the resulting query string:
> SELECT * FROM recent_news WHERE topic=''; DELETE FROM user_logins; SELECT
''
>
> If you allow multiple queries in one string, there is no way to prevent
this.
> If you disallow multiple queries, there are still attacks that are
possible.
>
> This is why it is vital to parse and validate user input. If you are
asking
> for an integer, check that it is. If you are asking for a string, quotes
etc.
> need to be escaped (AFAICT the stuttgart url describes a function that
lets
> you do this - you still need to call it).
>
> The first URL seems to deal with an old bug that meant a cunning attacker
> could bypass your escaping. It is still vital that the application (or
some
> middle layer) validates and checks all untrusted (and preferably all
trusted)
> input. All standard database layers (Perl/PHP/Java, whatever) supply tools
> for this.
>
> Your particular issue with \n is just down to PG's standard string
parsing -
> not really related.
> --
> Richard Huxton
> Archonet Ltd
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: sqllist@coralindia.com
Subject: Re: how to preserve \n in select statement
In-Reply-To: <004c01c3c86f$389c5380$0f32a8c0@denisnew>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox