Безопасность PostgreSQL по сравнению с MySQL и т. Д.

Question

Столкнувшись с некоторыми смелыми утверждениями о ненадежности PostgreSQL (при этом приветствуя безопасность MySQL), я бы хотел узнать мнение другого человека:

• «PostgreSQL небезопасен из-за множественного выбора» - я бы предположил, что «множественный выбор» - это то, что я бы назвал «подселектами», но я могу ошибаться. Текущие версии MySQL поддерживают подвыборы, но согласно [1] некоторые библиотеки могут не поддерживать или могли их отключить. Может ли это быть причиной претензии или я что-то упускаю здесь?
• «Инъекции SQL проще всего использовать с PostgreSQL» - IMHO инъекции SQL - это проблема приложения / библиотеки и просто допустимые запросы SQL, поэтому между базами данных нет реальной разницы, верно?!
• «Мне нравится PostgreSQL за получение корневых разрешений, поскольку у него так много дыр в безопасности» - во-первых, я бы предположил, что послужной список безопасности PostgreSQL примерно такой же, как у MySQL (не мог найти много по этому поводу)? Во-вторых, запуск PostgreSQL с правами root - просто глупая идея. Или в этом есть что-то действительное?

Я бы сказал, что PostgreSQL лучше осведомлен о безопасности, чем MySQL (поддержка ролей, больше методов аутентификации, ...), но сама база данных, как правило, оказывает очень ограниченное влияние на безопасность приложения. Или я здесь упускаю какие-либо аргументы?

[1] Является ли MySQL более устойчивым к атакам внедрения SQL, чем PostgreSQL (под Perl / DBI)?

PS: MySQL и PostgreSQL - отличные продукты - не нужно никаких обсуждений, не связанных с безопасностью; -)

Answer 1

"По умолчанию PostgreSQL является, пожалуй, самой защищенной базой данных из доступных ..."

Руководство по взлому баз данных

PostgreSQL isnЭто небезопасно из-за операторов с несколькими запросами, это нормальная функциональность, но она недоступна в старых драйверах MySQL.MySQLi-драйвер также поддерживает операторы нескольких запросов.SQL Server, Oracle, DB2 и почти все другие базы данных имеют эту опцию, MySQL просто очень поздно ее реализовала.Опоздание не означает «безопасный».

Внедрение SQL является серьезной ошибкой, допущенной программистом, а не базой данных.Основная проблема лежит за клавиатурой, это тот, кто виноват.

Используйте подготовленные операторы и ПРЕКРАТИТЕ доверие пользователей, так вы избежите внедрения SQL и других проблем безопасности.Хранимые процедуры также могут помочь снизить влияние SQL-инъекций, их очень легко использовать в PostgreSQL.Проверьте также quote_ident () , если у вас есть динамические имена таблиц или столбцов в вашем SQL.В MySQL отсутствуют подобные функции.

PostgreSQL имеет ROLES и унаследованные роли для установки и поддержки разрешений.Если вы даете всем права суперпользователя (root) всем, вы создаете проблемы.Если нет, вы в безопасности.В разрешениях суперпользователя нет известных ошибок, утверждение о дырах в безопасности в этих разрешениях звучит как FUD, потому что нет никаких доказательств.

Вы проверяли SE PostgreSQL ?Это безопасность на более высоком уровне.PostgreSQL версии 9.1 (бета-версия на данный момент) также имеет новые опции для SE.MySQL может только мечтать об этом уровне безопасности.

Answer 2

По моему личному мнению, дискуссии о безопасности с использованием различных технологий баз данных часто совершенно беспочвенны, и во многих случаях те, кто быстро указал пальцем на одну или другую, вероятно, не понимают, что причиной разлива данных была не из-за базы данных, но потому, что они не защитили свое приложение должным образом, но не могут признать ошибку, таким образом, возлагая вину на других. По крайней мере, до сих пор у меня были споры о безопасности, связанные с любой технологией баз данных.

Хороший пример, SQL-инъекция вообще не является ошибкой базы данных. SQL - это стандартизированный язык, принятый как MySQL, так и PostgreSQL (и Oracle, и другими ...). SQL-инъекция - это манипулирование языком структурированных запросов, а не недостаток безопасности сервера. Причиной этого является тот факт, что приложение неправильно обработало входные данные. Нельзя утверждать, что одна база данных, использующая один и тот же стандартизированный язык, менее защищена от непреднамеренного манипулирования запросами, чем другая база данных, использующая ту же технологию, поэтому тот, кто сказал вам, что SQL-инъекция - это больше проблема одной из этих двух баз данных. не понимает, что такое SQL-инъекция.

Что касается запуска PostgreSQL от имени пользователя root, вы не должны запускаться от имени пользователя root. Запуск службы на сервере от имени пользователя root всегда плохая идея, опять же, ничего не связано с серверами.

У меня очень мало опыта работы с PostgreSQL, но я скажу, что MySQL имеет выдающуюся систему разрешений, которая позволяет пользователям делегировать набор доступных команд в определенном списке баз данных на клиентских компьютерах с выбранным списком. PostgreSQL может быть сделан иначе, но я бы с трудом согласился с тем, что безопасность одного из них, когда он связан с аутентификацией и учетными записями пользователей, очень важна для другого.

Answer 3

В дополнение к ответу Скотта (+1) я бы добавил несколько вещей:

• SQL-инъекции с подзапросами невозможны в MySQL, но вы можете сделать SQL-инъекцию с UNION-запросами , немного дольше, но с точки зрения раскрытия информации инъекции UNION просто необходимы. А SQL-инъекция чаще всего используется для раскрытия информации, а не для DROP table foo; инструкций.
• PostgreSQL запрещает межбазисные запросы, если вы не используете специальные поведения dbi_connect. Так что в условиях разделения баз данных лучше.
• PostgreSQL имеет большое управление привилегиями пользователей / групп , и вы можете иметь очень тонкую политику SQL для всех объектов и данных для каждого пользователя или группы. Я бы сказал, что это даже лучше, чем у вас в MySQL (но я могу ошибаться). А с точки зрения подключения к базе данных управление учетными данными пользователя у вас есть действительно более мощный инструмент, вы можете сопоставить пользователей вашей базы данных, например, с внешней системой единого входа.
• Тогда, и для меня это главное. С точки зрения безопасности один из способов иметь надежную и надежную базу данных - это ограничить точки входа в приложение и управлять целостностью данных и тяжелыми манипуляциями с данными в базе данных . Если вы ограничиваете точки входа своего приложения некоторыми хранимыми процедурами и представлениями, некоторыми сохраненными выражениями, а затем выполняете важные действия в некоторых других хранимых процедурах и триггерах, или если вы отображаете только представления для пользователей, и используете правила для выполнения реальных заданий записи и т.д. Видите, что я имею в виду? Хорошо, что для создания такого рода приложений PostgreSQl действительно лучший из двух.

Answer 4

Помещать это здесь в качестве комментария - не самое подходящее место для этого:

Мультиселект - это запрос, подобный:

mysql_query("SELECT x FROM y; SELECT p FROM q;");

Два отдельных запроса, один вызов одного запроса.Это классический сценарий внедрения SQL-кода, когда предоставленные пользователем данные выполняют совершенно другой запрос, чем предполагал кодер, например атака Bobby Tables .

MySQL / PHP защищены от этого толькоВ силу того, что драйвер MySQL не позволяет такие конструкции.Он по-прежнему полностью уязвим для инъекций подзапросов, но не допускает двух совершенно независимых запросов в одном выражении.

Answer 5

Установка PostgreSQL по умолчанию предотвращает очень строгий доступ к базе данных через файл pg_hba.conf. Это зависит от системного администратора, как база данных будет выставлена ​​внешнему миру. После настройки все зависит от приложения, чтобы предотвратить «атаки» БД.