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 approximation would be to raise an error when you encounter a
query string that isn't contained in some special configuration file.
This could be implemented in a client library, but that means that
you're still entirely as vulnerable; any client that chooses not to
use that library won't be protected.
It would be a mighty attractive thing to have something at the server
level to protect against the problem.
If by "the problem" you mean SQL injection attacks in general, I
strongly suspect you are chasing a mirage.
Someone mentioned upthread that the best way to secure the database was
to require that all access be via stored procedures. You can actually go
quite a logn way down that road. I have seen it done quite successfully
in a Fortune 50 company. In effect you are getting out of the game of
catching insecure operations by not allowing your user direct access to
them at all. (This approach also has huge benefits in allowing
optimisation without disturbing client code).
But this requires work by the DBA. I have some ideas about how we could
make it a whole lot easier and more workable, but they probably don't
belong in this thread.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
