Могу ли я быть невосприимчивым к инъекциям 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 на «"; DROP DATABASE; - ".

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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

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