On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian <bruce@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.
-Harold