Re: [SECURITY] DoS attack on backend possible

From: ngpg(at)grymmjack(dot)com
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [SECURITY] DoS attack on backend possible
Date: 2002-08-20 13:08:26
Message-ID: Xns92705D648F8D09wn7t0983uom3iu23n@64.49.215.80
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

cjs(at)cynic(dot)net (Curt Sampson) wrote in
> On Mon, 19 Aug 2002 ngpg(at)grymmjack(dot)com wrote:
>
>> $input = "user'name";
>> INSERT INTO db (name) VALUES ('$input');
>>
>> will fail because the ' in the input needs to be escaped with a
>> backslash.
>
> It will fail because you're doing this a very, very, very bad way.
> Why rewrite this kind of stuff when the vendor has already made
> correct code available?
>
> PreparedStatement stmt = connection.prepareStatement(
> "INSERT INTO db (name) VALUES (?)");
> stmt.setString("user'name");
> stmt.execute();
>
> cjs

Curt:
I am not doing it this way, I am trying to point out that doing it without
"doing something" (whether it be using preparedstatement or WHATEVER), is,
as you say, very very very bad (I am agreeing with you). I am further
saying that whatever it is you do, you should also be doing some other
simple validation, like the length of the inputs, because most inputs wont
be over 255 chars before being prepared. This is just an example, but you
should do whatever validation would apply to you (and this is probably true
coding for any user input whether it involves a db or not). I am just
saying this is good practice in my opinion and had these people that
brought up the issue in the first place were doing it, then pgsql's
shortcomings would not have been as severe a problem. Things I am not
saying are: its ok for pgsql to have this DoS problem; its the frontends
responsibility to maintain data integrity not the backend.

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2002-08-20 16:37:03 pgsql-server/src/test/regress/expected domain. ...
Previous Message Michael Meskes 2002-08-20 12:23:37 pgsql-server/src/interfaces/ecpg Tag: ecpg_big ...

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-20 13:39:58 Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Previous Message Jan Wieck 2002-08-20 13:05:03 Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in