MySQL более устойчив к атакам SQL-инъекций, чем PostgreSQL (под Perl / DBI)?

Question

Я рассматриваю Perl-приложение на базе Linux, которое содержит обработчик входа с вездесущим

my $ sth = $ DB-> prepare ("ВЫБРАТЬ пароль из паролей, где userid = '$ userid'") или die; $ sth-> выполнить или умереть; ...

, где $ userid инициализируется из (небезопасного, нефильтрованного) пользовательского веб-ввода.

Хорошо известно, что в документации DBI рекомендуется изменить этот код для использования заполнителя "?" вместо '$ userid' для безопасности.

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

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

Под PostgreSQL ввод '; делать плохие вещи здесь; и здесь; будет аварийно завершить вход в систему cgi, как ожидалось, и выполнить плохие вещи.

Что было неожиданно, так это то, что MySQL противостоял этой атаке. Это заставило меня задуматься, была ли какая-то настройка для DBD :: MySQL или где-либо еще, которая ограничивала подготовку 1 оператором на вызов, или была устойчива к MySQL каким-либо другим способом.

Насколько я понимаю, MySQL вообще не устойчив к SQL-инъекциям.

Это не вопрос чисто техник устранения SQL-инъекций; об этом, возможно, см. Как избежать атак с использованием SQL-инъекций? .

Вопрос в том, является ли MySQL более устойчивым, чем PostgreSQL, к атакам с использованием SQL-инъекций под DBI-интерфейсом PERL, и почему это может иметь место?

Answer 1

Защита от инъекционных атак - это не ответственность базы данных, а ответственность разработчика. Если разработчик пишет код, который создает запросы путем объединения строк, полученных из пользовательского ввода, полученные запросы будут уязвимы для атак с использованием инъекций, и весь код, потраченный на очистку и т. Д., Является ИМХО пустой тратой времени. Если код написан для использования параметризованных запросов, а пользовательский ввод используется как значения параметров, результирующие запросы будут достаточно защищены от атак внедрения. (И мне было бы интересно услышать, как можно осуществить инъекцию через значение параметра).

Делись и наслаждайся.

Answer 2

Клиентская библиотека MySQL, по-видимому, ограничена одним оператором на вызов по умолчанию (я столкнулся с ним с помощью PHP).

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

Answer 3

Нет, фактически MySQL почти категорически менее безопасен, в этом случае создается впечатление, что операторы подготовки вообще не выполняются на сервере.

Поддержка подготовленной выписки (сервер сторона готовится) По состоянию на 3.0002_1, сервер сторона подготовить заявления были на по умолчанию (если ваш сервер был> = 4.1.3). По состоянию на 3.0009 они были отключены по умолчанию снова из-за проблем с подготовленными API заявления (все другие mysql разъемы установлены таким образом, пока C Проблемы с API решены). Требование использовать подготовленные заявления по-прежнему остается, что у вас есть сервер '> = 4.1.3'

Для использования на стороне сервера подготовлено заявления, все, что вам нужно сделать, это установить переменная mysql_server_prepare в соединение:

$ dbh = DBI-> connect ( "DBI: MySQL: базы данных = тест, хост = локальный; mysql_server_prepare = 1", "", "", {RaiseError => 1, AutoCommit => 1});

• Примечание: разделителем для этого параметра является ';'

Есть много преимуществ использования на стороне сервера готовят заявления, в основном если вы выполняете много вставок из-за того факта, что один заявление готово принять несколько значений вставки.

Чтобы убедиться, что шаг 'make test' проверяет, работает ли подготовка сервера, вам просто нужно экспортировать env переменная MYSQL_SERVER_PREPARE:

export MYSQL_SERVER_PREPARE = ​​1

Предположительно, они подготовлены на сервере в PostgreSQL.

Что касается безопасности, вы просто делаете это неправильно: используйте ?, как вы сказали. В противном случае вы просто используете, что Postgres может подготовить несколько утверждений, и это не является чем-то отрицательным. Я полагаю, что MySQL, вероятно, может сделать это тоже, единственное отличие здесь заключается в том, что DBD :: MySQL утверждает, что проблемы C API исключают использование подготовок на стороне сервера, поэтому они полагаются на какой-то другой источник как авторитетный для сервера. Прямо сейчас DBD :: MySQL, вероятно, использует функцию C в библиотеке mysql, которая предшествовала MySQL с подготовкой на стороне сервера (мое предположение pre 4.1.3).

Answer 4

Может быть трудно, если не невозможно, использовать универсальное дезинфицирующее средство против инъекций SQL.

Добавлено [Как прокомментировано, при правильном использовании DBI и с помощью клиентской библиотеки БД, инъекции могут быть сведены к минимуму при подготовке оператора SQL. Тем не менее, важно помнить, что очистка пользовательского ввода также включает в себя логику приложения, которая не зависит от используемой БД. Например, использование учетных данных другого пользователя может предоставить действительный и безопасный оператор, но с непредвиденными последствиями. Во всяком случае, это идет дальше, чем заданный вопрос.]

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