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.
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 ... |
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 |