-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> How often do people code comments into prepare statements in perl
> or the equivalent in java, ruby, etc?
>
> Do you put comments in your perl prepare statements?
Does it matter? It shouldn't. They are comments.
> If comments count as a stat
Chris Browne wrote:
[EMAIL PROTECTED] (Florian Weimer) writes:
* Thomas Mueller:
What do you think about it? Do you think it makes sense to implement
this security feature in PostgreSQL as well?
Can't this be implemented in the client library, or a wrapper around it?
A simple
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
This might seem sillly, but...
...are comments going to be considered statements for the purpose of
this knob?
(hoping the anwer is "yes")
Are you trying to say we should forbid comments? No thank you.
No.
When psql (for
[EMAIL PROTECTED] (Florian Weimer) writes:
> * Thomas Mueller:
>
>> What do you think about it? Do you think it makes sense to implement
>> this security feature in PostgreSQL as well?
>
> Can't this be implemented in the client library, or a wrapper around it?
> A simple approximation would be to
Darren Reed <[EMAIL PROTECTED]> writes:
> This might seem sillly, but...
> ...are comments going to be considered statements for the purpose of
> this knob?
> (hoping the anwer is "yes")
Are you trying to say we should forbid comments? No thank you.
regards, tom lane
--
This might seem sillly, but...
...are comments going to be considered statements for the purpose of
this knob?
(hoping the anwer is "yes")
Darren
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
* Thomas Mueller:
> What do you think about it? Do you think it makes sense to implement
> this security feature in PostgreSQL as well?
Can't this be implemented in the client library, or a wrapper around it?
A simple approximation would be to raise an error when you encounter a
query string that
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> Oh, heaven. I can at least think of ways to use ENUM such that you
> can justify the trade-off. I can think of no excuse whatever for
> PQexec("COMMIT; BEGIN"). That's just lazy and sloppy.
> Note also that more recent releases, concurrent with th
On Fri, May 02, 2008 at 03:58:01PM -0400, Chris Browne wrote:
> Andrew Sullivan recently had some choice words about the merits of
> ENUM; I think the same applies to drivers that do
> PQexec("COMMIT;BEGIN")...
Oh, heaven. I can at least think of ways to use ENUM such that you
can justify the tr
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Darren Reed wrote:
>
>> Because interacting with the database is always through an action
>> that you do and if you're being half way intelligent about it, you
>> are always checking that each action succeeded before going on to
>> the next.
>
> Hmm, it
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Hmm, it won't be pretty for the drivers that do PQexec("COMMIT; BEGIN").
> The driver will think that it's in a transaction when in fact the second
> command in the string has been ignored, and so it's not ...
Any driver that is doing that sh
Darren Reed wrote:
> Because interacting with the database is always through an action
> that you do and if you're being half way intelligent about it, you
> are always checking that each action succeeded before going on to
> the next.
Hmm, it won't be pretty for the drivers that do PQexec("COMMI
Darren Reed <[EMAIL PROTECTED]> writes:
> Also, I think the "no-multistatement SQL" should default to on.
Not happening, for backwards-compatibility reasons.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
**Andrew Sullivan wrote:
On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:
> But it's true that preventing multi-statements adds a layer of
> idiot-proofness... a rather thin layer...
As I already said in a previous remark in this thread, I don't really
like partial security solutions.
W
On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:
> But it's true that preventing multi-statements adds a layer of
> idiot-proofness... a rather thin layer...
As I already said in a previous remark in this thread, I don't really
like partial security solutions.
What the "no multi-state
"Thomas Mueller" <[EMAIL PROTECTED]> writes:
>> 1. Inexpensive to implement
> Disabling literals wouldn't be much harder to implement I believe, but
> I don't know the PostgreSQL internals.
You're ignoring the client-side costs of repairing broken applications.
(If it only broke applications tha
Thomas Mueller wrote:
Disabling literals is still the only way to actually protect from SQL
injection. Except Meredith's libdejector, which is even a bit better
as far as I see, but requires more work from the developer. I don't
count Microsoft LINQ (or Java Quaere) currently because that would
Hi,
> disallow more than one SQL statement per PQexec.
I agree, it would help.
> 1. Inexpensive to implement
Disabling literals wouldn't be much harder to implement I believe, but
I don't know the PostgreSQL internals.
> 2. Unlikely to break most applications;
That's true.
> 3. Closes off
Sure, modifying the WHERE clause is still possible, but the attacker is
a lot more limited in what he can do if he can't tack on a whole new
command.
I hacked into a site like that some day to show a guy that you shouldn't
trust magicquotes (especially when you switch hosting providers and
On Thu, May 01, 2008 at 11:26:21AM -0400, Tom Lane wrote:
>
> 1. Inexpensive to implement;
> 2. Unlikely to break most applications;
> 3. Closes off a fairly large class of injection attacks.
>
> The cost/benefit ratio looks pretty good (unlike the idea that started
> this thread...)
That's a mu
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Andrew Sullivan" <[EMAIL PROTECTED]> writes:
>> The _principal_ trick with SQL injection is to fool the application
>> into somehow handing a ";" followed by an arbitrary SQL statement.
> They're the principal trick only because they're the most conveni
"Andrew Sullivan" <[EMAIL PROTECTED]> writes:
> The _principal_ trick with SQL injection is to fool the application
> into somehow handing a ";" followed by an arbitrary SQL statement.
> There are of course other things one can do, but most of them are
> constrained to abuse of statements your app
On Wed, Apr 30, 2008 at 05:33:38PM -0400, Tom Lane wrote:
> you're at risk of some clients being secure and some not. I thought
> what we were discussing was a server-side GUC parameter that would
> disallow more than one SQL statement per PQexec.
That was certainly what I was intending, yes.
T
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> void PQexec()
> {
> die();
> }
Actually disabling PQexec seems like a pretty poor decision; it breaks
working code to no purpose. Also, doing it on the client side means
you're at risk of some clients being secure and some not. I thought
wha
On Wed, Apr 30, 2008 at 10:20:09AM -0400, Andrew Sullivan wrote:
> On Tue, Apr 29, 2008 at 09:02:30PM -0400, Gregory Stark wrote:
> > Did you guys miss Tom's comment up-thread? Postgres already does this if you
> > use PQExecParams().
>
> I did, yes. Thanks for the clue. OTOH, I do see the OP's
* Gurjeet Singh <[EMAIL PROTECTED]> [080430 13:38]:
> Well, if the the query was:
>
> WITH CONSTANT c_jobrole = , CONSTANT c_dept =
> 10
> SELECT * FROM emp WHERE jobrole = c_jobrole and deptno = c_dept;
>
> And if the attack supplied a value 'clerk OR 1=1' the final query (after
> replacing co
On Wed, Apr 30, 2008 at 10:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> > Maybe we can extend the SQL's WITH clause do declare the constant along
> with
> > the query, and not separate from the query.
>
> > WITH CONSTANT c_jobrole = 'clerk', CONSTANT c
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> Maybe we can extend the SQL's WITH clause do declare the constant along with
> the query, and not separate from the query.
> WITH CONSTANT c_jobrole = 'clerk', CONSTANT c_dept = 10
> SELECT * FROM emp WHERE jobrole = c_jobrole and deptno = c_dept;
[ s
On Wed, Apr 30, 2008 at 8:52 PM, Thomas Mueller <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> Constants are just convenience: instead of constants, user defined
> functions can be used. This already works, however it's a bit verbose:
>
> CREATE FUNCTION STATE_ACTIVE() RETURNS VARCHAR AS
> $$ BEGIN RETURN
Hi,
Constants are just convenience: instead of constants, user defined
functions can be used. This already works, however it's a bit verbose:
CREATE FUNCTION STATE_ACTIVE() RETURNS VARCHAR AS
$$ BEGIN RETURN 'active'; END; $$ LANGUAGE PLPGSQL;
Usage is almost the same:
SELECT * FROM USERS WHERE
Could we also get a mode, where PREPARE would only be allowed for
queries of the form "SELECT * FROM func(?,?,?,?,?); :)
Actually, that is similar to the concept of "global prepared statements"
that I proposed some time ago, but I will not have time to write the
patch, alas...
Idea was t
Andrew Dunstan wrote:
Tino Wildenhain wrote:
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE
Hi,
> How many people are using literals in Java?
Not sure if I understood the question... In Java most people use
constants (final static). 'Checkstyle' can find 'magic numbers' in the
source code.
If the constants feature was very important in SQL, people would have
requested it, and it would
On Tue, Apr 29, 2008 at 09:02:30PM -0400, Gregory Stark wrote:
> Did you guys miss Tom's comment up-thread? Postgres already does this if you
> use PQExecParams().
I did, yes. Thanks for the clue. OTOH, I do see the OP's point that
it'd be nice if the DBA could enforce this rule. Maybe a way
On Tue, 29 Apr 2008, Josh Berkus wrote:
Did you guys miss Tom's comment up-thread? Postgres already does this if
you use PQExecParams().
Keen. Now we just need to get the driver developers to implement it. I
imagine Java does.
The JDBC driver takes a multi-command statement and splits i
On Tue, 2008-04-29 at 16:01 -0400, Aidan Van Dyk wrote:
> Most of my published applications *are* simple, and I tend to
> consolidate as much of my "business logic" in the database as possible
> and a "known" set of queries shared by all the related apps, relying
> heavily on view, triggers, and
Greg,
> Did you guys miss Tom's comment up-thread? Postgres already does this if
> you use PQExecParams().
Keen. Now we just need to get the driver developers to implement it. I
imagine Java does.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-h
"Josh Berkus" <[EMAIL PROTECTED]> writes:
>> (I sort of like the
>> suggestion up-thread, myself, which is to have a GUC that disables
>> multi-statement commands. That'd probably cover a huge number of
>> cases, and combined with some sensible quoting rules in client
>> libraries, would quite po
On Wed, Apr 30, 2008 at 1:48 AM, Thomas Mueller <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> For PostgreSQL the 'disable literals' feature would be great
> publicity:
>
>
'publicity' is something this community does not crave for, at least not
feature wise. If that were the case we would have had a milli
On Tue, 29 Apr 2008 22:18:48 +0200 Thomas Mueller wrote:
> For PostgreSQL the 'disable literals' feature would be great
> publicity: PostgreSQL would be the first only major database that has
> a good story regarding SQL injection. Yes it's not the magic silver
> bullet, but databases like MS SQL
> (I sort of like the
> suggestion up-thread, myself, which is to have a GUC that disables
> multi-statement commands. That'd probably cover a huge number of
> cases, and combined with some sensible quoting rules in client
> libraries, would quite possibly be enough.)
MySQL did this already.
--
[I know, I know, bad form]
On Tue, Apr 29, 2008 at 04:55:21PM -0400, Andrew Sullivan wrote:
> thinking they have to worry about that area of security at all. I
> think without a convincing argument that the proposal will even come
> close to covering most SQL injection cases, it's a bad idea.
To
Thomas,
> For PostgreSQL the 'disable literals' feature would be great
> publicity: PostgreSQL would be the first only major database that has
> a good story regarding SQL injection. Yes it's not the magic silver
> bullet, but databases like MS SQL Server, Oracle or MySQL would look
> really bad.
On Tue, Apr 29, 2008 at 04:33:01PM -0400, Andrew Dunstan wrote:
> Moreover, it seems unlikely that it will even cover the field. A partial
> cloak might indeed be worse than none, in that it will give some developers
> an illusion of having security.
I think this is a really important point, an
Thomas Mueller wrote:
Forbidding literals will break absolutely every SQL-using application on the
planet
Well, it's optional. If a developer or admin wants to use it, he will
know that it could mean some work. Even if the feature is not enabled,
it's still good to have it. And using co
Hi,
For PostgreSQL the 'disable literals' feature would be great
publicity: PostgreSQL would be the first only major database that has
a good story regarding SQL injection. Yes it's not the magic silver
bullet, but databases like MS SQL Server, Oracle or MySQL would look
really bad.
> [literals..
* Gregory Stark <[EMAIL PROTECTED]> [080429 14:20]:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>
> > That said, though *I* like the idea (and since I develop against
> > PostgreSQL 1st and use params for my queries I would consider it a nice
> > tool to "keep me honest"), I can easily see that
Hi Martijn,
> > The problem is not only quotes. The problem is all kinds of user
> > input. For example: sql = "SELECT * FROM ORDERS WHERE ORDER_ID = " +
> > orderId; This is not a problem if orderId is a number. But what if
> > it's a String? For example "1 AND (SELECT * FROM USERS WHERE
> >
For example, some applications need to replace whole phrases:
$criteria = "WHERE $var1 = '$var2'"
This is a very common approach for dynamic search screens, and really not
covered by placeholder approaches.
Python, again :
params = {
'column1': 10,
'column2': "a st'rin
> If you're going to ask people to do significant revision of their
> apps to gain security, they're going to want it to work no matter
> what database they run their apps against. This is why you need
> a client-side solution such as tainting.
Or if people are going to re-write their applicatio
"Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
> That said, though *I* like the idea (and since I develop against
> PostgreSQL 1st and use params for my queries I would consider it a nice
> tool to "keep me honest"), I can easily see that the cost/benefit ratio
> on this could be quite low and make i
* Tom Lane <[EMAIL PROTECTED]> [080429 10:59]:
> "Tom Dunstan" <[EMAIL PROTECTED]> writes:
> > Damn, am I the only person who likes the idea?
>
> Just about. The reason that this idea isn't going anywhere is that its
> cost/benefit ratio is untenably bad. Forbidding literals will break
> absolut
Tino Wildenhain wrote:
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE ... and DROP CONSTANT
.
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> Damn, am I the only person who likes the idea?
Just about. The reason that this idea isn't going anywhere is that its
cost/benefit ratio is untenably bad. Forbidding literals will break
absolutely every SQL-using application on the planet, and in many
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE ... and DROP CONSTANT
..., example: CREATE CONSTA
On Tue, Apr 29, 2008 at 12:25 AM, Thomas Mueller
<[EMAIL PROTECTED]> wrote:
> What do you think about it? Do you think it makes sense to implement
> this security feature in PostgreSQL as well? If not why not? Does
> PostgreSQL have another solution or plan to solve the SQL injection
> problem
"Thomas Mueller" <[EMAIL PROTECTED]> writes:
> Also, programming languages such as Java don't support tainting. And it's
> again in the hand of the developer to use it, not use it, or use it in the
> wrong way. There should be a way for an admin to enforce using it, and using
> it correctly.
I be
zero developer pain
Actually it's not zero pain, but the main problem is: there is no way
to enforce using it.
Sure, there is no way to enforce it (apart from grepping the source for
pg_query() and flogging someone if it is found), but is it really
necessary when the right solution is eas
On Tue, Apr 29, 2008 at 01:37:37PM +0200, Thomas Mueller wrote:
> > any literal (i.e. not just strings) can be quoted, think of dates in
> > queries.
>
> The problem is not only quotes. The problem is all kinds of user
> input. For example: sql = "SELECT * FROM ORDERS WHERE ORDER_ID = " +
> order
Hi,
> Meredith's libdejector
1) The last activity was 2005-12-17 :-(
2) From the docs: "the techniques used ... are ... being explored for
patentability".
3) The tool validates the SQL statement. This is not required when
using parameterized queries.
4) An 'exemplar' query is required for each qu
On Tue, 29 Apr 2008 01:03:33 +0200, Brendan Jurd <[EMAIL PROTECTED]> wrote:
On Tue, Apr 29, 2008 at 7:00 AM, PFC <[EMAIL PROTECTED]> wrote:
I have found that the little bit of code posted afterwards did
eliminate
SQL holes in my PHP applications with zero developer pain, actually it
is
MOR
On Mon, Apr 28, 2008 at 08:55:34PM +0200, Thomas Mueller wrote:
> As you know, "SQL injection" is the main security problem of databases today.
>
> I think I found a solution: 'disabling literals'.
I personally think this is wrong, I often have schemas that mean I have
to do things like:
SELEC
On Tue, Apr 29, 2008 at 7:00 AM, PFC <[EMAIL PROTECTED]> wrote:
> I have found that the little bit of code posted afterwards did eliminate
> SQL holes in my PHP applications with zero developer pain, actually it is
> MORE convenient to use than randomly pasting strings into queries.
>
> You just
As you know, "SQL injection" is the main security problem of databases
today.
I think I found 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
* Thomas Mueller ([EMAIL PROTECTED]) wrote:
> As you know, "SQL injection" is the main security problem of databases today.
I think there's a fallacy there- it's the main security problem of
applications (particularly those on the web) today. It hasn't got much
at all to do with the database's se
Thomas,
What do you think about it? Do you think it makes sense to implement
this security feature in PostgreSQL as well? If not why not? Does
PostgreSQL have another solution or plan to solve the SQL injection
problem?
Have you seen Meredith's libdejector?
http://sourceforge.net/projects/libd
Hi,
As you know, "SQL injection" is the main security problem of databases today.
I think I found 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
67 matches
Mail list logo
