Re: Application name patch - v2

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Application name patch - v2
Дата
Msg-id 937d27e10910190438m24d7d5f5qff4fa3d111d0e78@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Application name patch - v2  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Application name patch - v2  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2009/10/19 Dave Page <dpage@pgadmin.org>:
>> On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule <pavel.stehule@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@myapp: LOG:  connection authorized: user=dpage database=postgres
>> dpage@myapp: LOG:  statement: set application_name='hax0red';
>> dpage@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Application name patch - v2
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Rejecting weak passwords