Ivan Sergio Borgonovo wrote:
That's better than nothing but it is still a lot of code duplication.
You've to write column names in the sql statement and in the array
and... column values are not contextual to the statement.
The apparent duplication in the example stems for its tutorial natur
Hi,
> The problem may be legacy code.
Of course. There is a lot of legacy code that needs to be made secure
('hardened'). The best solution is to use parameterized queries. To
find out what statements are still not doing that, first disable text
literals only. If some places are incorrect, the r
On Sun, 27 Apr 2008 11:55:18 -0400
Joe <[EMAIL PROTECTED]> wrote:
> Ivan Sergio Borgonovo wrote:
> > It'd be nice to have a wrapper that let you write prepared
> > statements this way:
> >
> > "select a.id, b.name from a join b on a.id=b.id where
> > a.status=$variable1 and b.id>$variable2 etc...
Ivan Sergio Borgonovo wrote:
It'd be nice to have a wrapper that let you write prepared statements
this way:
"select a.id, b.name from a join b on a.id=b.id where
a.status=$variable1 and b.id>$variable2 etc... but that's a pretty
good change to any language parser.
Python already supports s
On Sun, 27 Apr 2008 12:38:48 +0200
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> wrote:
> Once you've developers that are so patient to write stuff like:
>
> "select a.id, b.name from a join b on b.id=a.id where
> a.status='pending' and b.id>7 and b.status='logged'"
>
> into
>
> "select a.id, b.nam
On Sat, 26 Apr 2008 21:50:10 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> Agreed. My point was that to do what the OP wants, wouldn't it make
> more sense to just lobotomize libpq so it doesn't understand
> anything but prepared queries. Doesn't obviate the need for a
> client side languag
On Sat, 26 Apr 2008 23:24:59 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 26, 2008 at 9:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > IIRC there was some discussion recently of providing a mode in
> > which the server would reject PQexec strings containing more than
> > one
Hi,
> providing a mode in which the server would reject PQexec strings containing
> more than one query.
That wouldn't help a lot. The simple SQL injection is not detected:
ResultSet rs = stat.executeQuery(
"SELECT * FROM USERS WHERE PASSWORD='" + password + "'");
An attacker would only need
Hi,
> > Wouldn't it be much simpler to have a version of the libpq client lib
> > that only understands prepared queries?
That would be possible. However the problem is not 'prepared queries'
versus 'direct queries'. It is possible to use literals in prepared
queries:
PreparedStatement prep =
Hi,
> I fail to see how the backend could distinguish between a query sent by a
> query tool and a query sent by an "application".
The backend could use a different client library (a client library
that doesn't allow literals). But in this case two or three client
libraries are required.
Probab
Hi,
> but can't the developer allow literals again?
Executing the statement SET ALLOW_LITERALS should be restricted. The
application uses another user name / password and doesn't have to
access rights to enable it. Maybe the user name / password is
configured using JNDI, so the application devel
On Sat, Apr 26, 2008 at 9:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> IIRC there was some discussion recently of providing a mode in which
> the server would reject PQexec strings containing more than one query.
> I didn't care for it much at the time, but I think it would provide
> most of t
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Agreed. My point was that to do what the OP wants, wouldn't it make
> more sense to just lobotomize libpq so it doesn't understand anything
> but prepared queries.
I doubt that that particular lobotomization accomplishes much in
comparison to the pena
On Sat, Apr 26, 2008 at 9:42 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> > Wouldn't it be much simpler to have a version of the libpq client lib
> > that only understands prepared queries?
>
> You could do that, but there's still no way for it to know
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Wouldn't it be much simpler to have a version of the libpq client lib
> that only understands prepared queries?
You could do that, but there's still no way for it to know exactly how
the submitted query was constructed. This would block off the types
On Sat, Apr 26, 2008 at 3:32 PM, Thomas Kellerer <[EMAIL PROTECTED]> wrote:
> Thomas Mueller wrote on 26.04.2008 18:32:
>
> > Literals can still be used when using query tools, or in applications
> considered 'safe'.
> >
> I fail to see how the backend could distinguish between a query sent by a
>
Thomas Mueller wrote on 26.04.2008 18:32:
Literals can still be used when using query tools, or in applications considered 'safe'.
I fail to see how the backend could distinguish between a query sent by a query
tool and a query sent by an "application".
Thomas
--
Sent via pgsql-sql mailing l
On Sat, Apr 26, 2008 at 1:19 PM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> > > The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> > > by an administrator.
> > then it solves nothing...
> > what if the developer never SET ALLOW_LITERALS NONE
>
> As I have said, the
Hi,
> > The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> > by an administrator.
> then it solves nothing...
> what if the developer never SET ALLOW_LITERALS NONE
As I have said, the 'ALLOW_LITERALS NONE' mode is enabled by the
developer itself, or by an administrator. T
Hi,
> I think you missed April Fool's Day...
This is absolutely not an April Fool idea :-) I must have made a bad
job explaining my idea.
> This is just silly, as it makes life impossibly painful for users
You mean developers? No, developers should use parameterized queries anyway.
> (const
On Sat, Apr 26, 2008 at 11:32 AM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
>
> The 'ALLOW_LITERALS NONE' mode is enabled by the developer itself, or
> by an administrator.
then it solves nothing...
what if the developer never SET ALLOW_LITERALS NONE or
maybe i can inject "select * from tab where
"Thomas Mueller" <[EMAIL PROTECTED]> writes:
> SET ALLOW_LITERALS NONE;
I think you missed April Fool's Day...
This is just silly, as it makes life impossibly painful for users
(constants are hardly a useless part of SQL) and it doesn't really
plug any holes. As an example:
select * fro
Hi,
As you know, "SQL injection" is the main security problem of databases today.
I think I have a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes
23 matches
Mail list logo
