2009/10/19 Dimitri Fontaine <dfonta...@hi-media.com>: > Andrew Dunstan <and...@dunslane.net> writes: >> Pavel Stehule wrote: >>> 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. > > That's not how I parse Pavel's worries. I think what's he telling here > is that seeing how the new GUC will get used (filtering logs), it > happens that if you're vulnerable to SQL injection it could be worse > with the application name setting than without, because attacker would > hide its injections under a filtered-out application name. > > Not sure my saying is easier to parse than Pavel's, btw... > >> And no, it is not at all the same as changing the client's IP address. > > If you filter logs by IP to detect attackers, and will filter by > application name in the future, I can see how it compares. > > Now, I don't think Pavel's worries have much weight here because if > you're vulnerable to SQL injection you want to first fix this. And you > will want to give different (sub-)application names from within the same > connection, and the easier way to provide that is to change the GUC > value.
sure, you have to fix fulnerable application. But with some unsophisticated using %a and using wrong tools, the people can be blind and don't register an SQL injection attack. > > +1 for user settable GUC for setting application name. > -- > dim > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers