Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Dave Page on 19 Oct 2009 07:38 On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> >>> 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. >> >> If they're logging the statements (which they presumably are if >> looking for unusual activity), then they'll see the attack: >> >> dpage(a)myapp: LOG: connection authorized: user=dpage database=postgres >> dpage(a)myapp: LOG: statement: set application_name='hax0red'; >> dpage(a)hax0red: LOG: disconnection: session time: 0:00:20.152 >> user=dpage database=postgres host=[local] >> > > this is bad solution. yes, I can found probmlematics rows, but I'll > get ten or more larger log. This is available only when loging of > application name changes depend on own configuration setting. Why will you get 'ten or more larger log'? If you're looking for suspicious queries from SQL injection attacks, then you'll be logging queries anyway. The only additional log lines will be the hacker... My point is, that the query to change the app name is logged using the *original* app name, thus it will not be discarded by the log analysis tools in your scenario. -- 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 07:57 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>> >>>> 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. >>> >>> If they're logging the statements (which they presumably are if >>> looking for unusual activity), then they'll see the attack: >>> >>> dpage(a)myapp: LOG: Â connection authorized: user=dpage database=postgres >>> dpage(a)myapp: LOG: Â statement: set application_name='hax0red'; >>> dpage(a)hax0red: LOG: Â disconnection: session time: 0:00:20.152 >>> user=dpage database=postgres host=[local] >>> >> >> this is bad solution. yes, I can found probmlematics rows, but I'll >> get ten or more larger log. This is available only when loging of >> application name changes depend on own configuration setting. > > Why will you get 'ten or more larger log'? If you're looking for > suspicious queries from SQL injection attacks, then you'll be logging > queries anyway. The only additional log lines will be the hacker... It is not practical. I'll log errors. Usually SQL injection generates lot of errors. Loging all statements has not sense. What is difference bad and good SQL statement.? Maybe multistatements are good candidates for log as possible attackers statements. On highly load databases loging all statements significantly increase load :( > > My point is, that the query to change the app name is logged using the > *original* app name, thus it will not be discarded by the log analysis > tools in your scenario. > I thing, so change of original name should generate warning. Pavel > -- > 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 08:00 On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > It is not practical. I'll log errors. Usually SQL injection generates > lot of errors. Loging all statements has not sense. What is difference > bad and good SQL statement.? Maybe multistatements are good candidates > for log as possible attackers statements. On highly load databases > loging all statements significantly increase load :( Ahh, I see. >> My point is, that the query to change the app name is logged using the >> *original* app name, thus it will not be discarded by the log analysis >> tools in your scenario. >> > > I thing, so change of original name should generate warning. Well, if other people think that's necessary, it's certainly possible. -- 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: daveg on 19 Oct 2009 08:14 On Mon, Oct 19, 2009 at 01:00:28PM +0100, Dave Page wrote: > On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > > It is not practical. I'll log errors. Usually SQL injection generates > > lot of errors. Loging all statements has not sense. What is difference > > bad and good SQL statement.? Maybe multistatements are good candidates > > for log as possible attackers statements. On highly load databases > > loging all statements significantly increase load :( > > Ahh, I see. > > >> My point is, that the query to change the app name is logged using the > >> *original* app name, thus it will not be discarded by the log analysis > >> tools in your scenario. > >> > > > > I thing, so change of original name should generate warning. > > Well, if other people think that's necessary, it's certainly possible. I have clients working around the lack of this feature by simply prepending a single line comment to their sql in the application to supply the app name. eg: -- monthly_report monthly_process.py:524 select wev from foo; This feature would be very handy, but not if it requires special permission to use it. -dg -- David Gould daveg(a)sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects. -- 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: Dimitri Fontaine on 19 Oct 2009 05:35
Andrew Dunstan <andrew(a)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. +1 for user settable GUC for setting application name. -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |