On Tue, Jan 21, 2014 at 5:22 PM, Mark Kirkwood <mark.kirkw...@catalyst.net.nz> wrote: > On 22/01/14 13:32, Harold Giménez wrote: >> >> On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian <br...@momjian.us> wrote: >>> >>> On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote: >>>> >>>> I don't know of a client where it can't be overridden. The friction >>>> occurs when by default it sets it to something useful to a developer >>>> (useful eg: to find what process is holding a lock), but is not >>>> possible to conceal from other users on the same cluster. If this were >>>> an in-premise or private cluster the point is moot. >>>> >>>> Furthermore consider when even using application_name for it's >>>> original intended use. On a shared environment as I'm describing here, >>>> that makes it possible for an attacker to identify what apps connect >>>> to a given server, or on the other hand is a way to find out where a >>>> given application stores its data, which can be used for a more >>>> targeted attack. >>> >>> >>> So security through obscurity? Why wouldn't the attacker just try all >>> the app methods at once and not even bother looking at the application >>> name? >> >> >> A malicious attacker may want to attack or harm `app1`. They write a >> script that provisions databases and check in pg_stat_activity until >> they find an application_name of `app1`. Having found the database >> holding app1's data, they then use a targeted attack on postgres, say >> a privilege escalation attack or any other vulnerability we don't know >> exists yet. Without application_name, the attacker would be unable to >> find the target database host to attack. >> > > If said malicious attacker can log into postgres and issue its own queries, > and connect to other database then you are in serious trouble already.
They can connect to their database, but not other databases in the cluster. > > I also wonder that if such an attacker knows the application name, that > would suggest that they have access to the application server and are able > to read its config files...which would probably also contain the host and db > name too (and possibly the password in some unfortunate cases)! No, I am considering something along the lines of www.foobar.com would have an application_name =~ '%foobar%' > > In addition people normally name app users and app dbs in a fairly > predictable way (e.g 'finance' app uses 'finance' user to connect to > 'finance' db), so I'm not seeing much value in trying to hide application > name. Some database service providers like Heroku Postgres generate role names and passwords, which are not predictable and users cannot change. Regards, -Harold -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
