Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries |
| Дата | |
| Msg-id | 7344.1266762191@sss.pgh.pa.us обсуждение |
| Ответ на | Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries (Pavel Stehule <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
Pavel Stehule <pavel.stehule@gmail.com> writes:
> * Last two months I spent some time with preparing workshops about SQL
> injection. PostgreSQL has only one issue related to this topic. It
> allows multi queries. With this feature any successful injection can
> have much more destructive impact. Now we have a GUC per user. I know,
> we cannot break multiqueries without breaking basic functionality. But
> we can break multiple queries on top level for some selected users -
> (web application roles). Then we are able to configure database for
> "secure web access". >>It isn't protection against SQL injection<<.
This seems like a waste of effort. It is already the case that multi
queries are forbidden when submitting through the extended query
protocol. All that an app has to do is not use simple protocol ---
which, if it's trying to be secure, it's already not using because
it needs out-of-line parameters.
There's no need for yet another GUC.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера