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-21 21:28:52
Message-ID: Xns9271B17F97FA9wn7t0983uom3iu23n@64.49.215.80
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Weimer(at)CERT(dot)Uni-Stuttgart(dot)DE (Florian Weimer) wrote

> ngpg(at)grymmjack(dot)com writes:
>
>> if you are going to be passing any user input to the database, you
>> must/should validate in some manner before blindly passing it to the db.
>> The db can and should guarantee data integrity, but the database cannot
>> read your mind when it comes to how you structure your queries.
>
> [example of SQL injection attack deleted]
>
> This is not the problem at hand. SQL injection attacks can be avoided
> easily. Bugs in the conversion of strings to internal PostgreSQL
> objects are a different matter, though, and usually, devastating
> effects cannot be avoided by (reasonably complex) checks in the
> frontend.
>

yeah i wasnt aware that adding a if(strlen($input) > SOME_REASONABLE_MAX)
was complex. the sql injection attack was just an(other) example of why
you do not simply forward user input to the backend. all i was trying to
point out is that most of these buffer overflows in the backend can be
avoided just as easily as the sql injection attack.

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian - CVS 2002-08-21 21:33:56 pgsql-server/src/backend/utils/mb/conversion_p ...
Previous Message Peter Eisentraut - PostgreSQL 2002-08-21 20:42:27 pgsql-server/src nls-global.mk backend/Makefil ...

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-21 21:34:18 Re: Build failure in current CVS
Previous Message Bruce Momjian 2002-08-21 21:14:53 Re: Large file support available