Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Dave Page on 19 Oct 2009 04:44 On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > Then we have to divide this value to two independent values like > application_name and application_state. How does that make any difference? That just means we have two values, at least one of which is still userset, and means an additional field in the logs and stats view etc. >>> I see this as security hole. It allows special SQL injection. >> >> How so? >> > You change identity. If any application is vulnerable to SQL > injection, then this value is nice goal. Are you saying that if your application is vulnerable, then the user may be able to masquerade as something else? If that's the case (and it's a problem for you), then there's a good chance you've got far bigger problems to worry about. This is not intended as a security mechanism, merely as a convenient way to identify what a backend is being used for. It doesn't remove any of the existing properties of the connection that the user cannot change (PID, current query, current user, host IP etc). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 Oct 2009 04:57 2009/10/19 Andrew Dunstan <andrew(a)dunslane.net>: > > > Pavel Stehule wrote: >> >> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >> >>> >>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> >>> wrote: >>> >>>> >>>> I dislike write access to app name guc for user too. It's not safe. >>>> Maybe only super user can do it? >>>> >>> >>> That'll render it pretty useless, as most applications wouldn't then >>> be able to set/reset it when it makes sense to do so. >>> >> >> But application can do it simply via connection string, no? Mostly >> applications has connection string in configuration, so I don't see >> problem there. And if I would to allow access, then I could to wrap >> setting to security definer function. >> >> I see this as security hole. It allows special SQL injection. >> >> > > > How is it any more a security hole than any other setting that the user can > alter with an arbitrary string value (e.g. custom options)? > Others GUC has not important role in logs. It's similar as possibility to change client IP address. > cheers > > andrew > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 Oct 2009 05:01 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> Then we have to divide this value to two independent values like >> application_name and application_state. > > How does that make any difference? That just means we have two values, > at least one of which is still userset, and means an additional field > in the logs and stats view etc. > >>>> I see this as security hole. It allows special SQL injection. >>> >>> How so? >>> >> You change identity. If any application is vulnerable to SQL >> injection, then this value is nice goal. > > Are you saying that if your application is vulnerable, then the user > may be able to masquerade as something else? If that's the case (and > it's a problem for you), then there's a good chance you've got far > bigger problems to worry about. > > This is not intended as a security mechanism, merely as a convenient > way to identify what a backend is being used for. It doesn't remove > any of the existing properties of the connection that the user cannot > change (PID, current query, current user, host IP etc). There are some log parser's and analysers. So people use reduced log often. The reductions rules should be based on application name. Why not? And when somebody modifies to appliacation name, then these logs finish in '/dev/null. regards Pavel Stehule > > > -- > Dave Page > EnterpriseDB UK: Â http://www.enterprisedb.com > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 19 Oct 2009 05:03 On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > There are some log parser's and analysers. So people use reduced log > often. The reductions rules should be based on application name. Why > not? And when somebody modifies to appliacation name, then these logs > finish in '/dev/null. So if your insecure app worries you, just don't use %a in the log prefix, or ignore the column in the CSV logs. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 19 Oct 2009 05:12
Pavel Stehule wrote: > 2009/10/19 Andrew Dunstan <andrew(a)dunslane.net>: > >> Pavel Stehule wrote: >> >>> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>> >>> >>>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> >>>> wrote: >>>> >>>> >>>>> I dislike write access to app name guc for user too. It's not safe. >>>>> Maybe only super user can do it? >>>>> >>>>> >>>> That'll render it pretty useless, as most applications wouldn't then >>>> be able to set/reset it when it makes sense to do so. >>>> >>>> >>> But application can do it simply via connection string, no? Mostly >>> applications has connection string in configuration, so I don't see >>> problem there. And if I would to allow access, then I could to wrap >>> setting to security definer function. >>> >>> I see this as security hole. It allows special SQL injection. >>> >>> >>> >> How is it any more a security hole than any other setting that the user can >> alter with an arbitrary string value (e.g. custom options)? >> >> > > Others GUC has not important role in logs. It's similar as possibility > to change client IP address. > > That doesn't even remotely answer the question. How is such a thing a vector for an SQL injection attack, that does not apply to other GUCs? If your answer is that log parsers will try to inject the values, then it those programs that need to be fixed, rather than restricting this facility in a way that will make it close to pointless. And no, it is not at all the same as changing the client's IP address. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |