Имею ли я иммунитет к SQL-инъекциям, если использую хранимые процедуры?

Question

Допустим, в базе данных MySQL (если это имеет значение).

Answer 1

Нет, вы не будете в полной безопасности. Как уже упоминали другие, параметризованные запросы - это всегда путь, независимо от того, как вы обращаетесь к базе данных.

Это небольшая городская легенда, что с проками вы в безопасности. Я думаю, что причина, по которой люди находятся в этом заблуждении, заключается в том, что большинство людей предполагают, что вы будете вызывать прок с параметризованными запросами из вашего кода. Но если вы этого не сделаете, например, если вы сделаете что-то подобное ниже, вы будете широко открыты:

SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();

Потому что вы используете нефильтрованный контент от конечного пользователя. Еще раз, все, что им нужно сделать, это завершить строку (" ;; "), добавить свои опасные команды и бум - вы попали.

(Кроме того, если вы находитесь в Интернете, не извлекайте нефильтрованный мусор из строки запроса браузера - это делает абсурдным делом чрезвычайно плохие вещи с вашими данными.)

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

Должен заметить, что я не антипрок. Procs может быть очень полезен для решения определенных проблем с доступом к данным. Но проки не являются «серебряным пули» для инъекций SQL.

Answer 2

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

Если вы вызываете хранимую процедуру, добавляя аргументы путем конкатенации, я все равно могу добавить случайный запрос в конце одного из полей ввода - например, если у вас есть CALL CheckLogin @username = '$ username', @ password = '$ password', с $ -things, представляющими непосредственно объединенные переменные, ничто не мешает мне изменить переменную $ password на read " '; DROP DATABASE; - & Quot;.

Очевидно, что если вы очистите входные данные заранее, это также поможет предотвратить внедрение SQL, но это может отфильтровать данные, которые не должны были быть очищены.

Answer 3

Это зависит от того, что делают ваши сохраненные процессы. Если они динамически генерируют SQL на основе своих параметров, а затем выполняют этот SQL, то вы по-прежнему уязвимы. В противном случае у вас гораздо больше шансов, что все будет хорошо, но я не решаюсь говорить на 100% уверенно!

Answer 4

неа.Если вы создаете SQL, вызывающий хранимую процедуру, вы все еще являетесь целью.

Вам следует создавать параметризованные запросы на стороне клиента.

Answer 5

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

Answer 6

Хранимые процедуры не являются гарантией, потому что на самом деле уязвим любой динамический код, который включает в себя код внутри хранимых процедур и динамически генерируемые вызовы хранимых процедур.

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

Преимущества хранимой архитектуры, основанной на procs, в значительной степени (я не уверен, что это возможно на 100%) заключается в том, что внедрение может даже несколько защищаться (но не идеально) для динамического кода на стороне клиента, поскольку

Только разрешения EXEC предоставляются для любого пользовательского контекста, к которому подключается приложение, поэтому любые запросы SELECT, INSERT, UPDATE, DELETE просто не будут выполнены. Конечно, DROP и т.д. не должны быть разрешены. Таким образом, любая инъекция должна быть в форме EXEC, поэтому, в конечном счете, будут доступны только те операции, которые вы определили на вашем уровне SP (не произвольный SQL) для внедрения.

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

Answer 7

Кроме того, рассмотрите возможность использования мелкозернистого доступа к базе данных (также называемого обычно управлением доступом на основе ролей). Основной пользователь вашей базы данных должен иметь именно те разрешения, которые необходимы для его работы, и ничего более. Не нужно создавать новые таблицы после установки? Отзовите это разрешение. У вас нет законной необходимости работать как sysdba? Тогда не надо! Скрытая инъекция, инструктирующая пользователя «DROP DATABASE» будет заблокирован, если пользователю не предоставлено это разрешение. Тогда все, о чем вам нужно беспокоиться, это операторы SELECT с утечкой данных.