Можно ли настроить SqlServer так, чтобы он не выполнял хранимые процедуры, представленные в виде строк?

Question

Сценарий A:

SqlConnection con = new SqlConnection(myConnString);
SqlDataAdapter adp = new SqlDataAdapter("EXEC spGetUserInfo 42", con);
DataSet ds;
adp.Fill(ds);

Сценарий B:

SqlConnection con = new SqlConnection(myConnString);
SqlCommand cmd = new SqlCommand();
cmd.Connection = con;
cmd.CommandText = "spGetUserInfo";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add(new SqlParameter("@UserID", 42));
SqlDataAdapter adp = new SqlDataAdapter(cmd);
DataSet ds;
adp.Fill(ds);

Вопрос

В обсуждении того, как защитить SqlServer от атак SQL-инъекций отдельно от модификации кода основного приложения, вызывающего базу данных, был поднят вопрос о том, можно ли настроить SqlServer так, чтобы он просто не выполнял хранимые процессы, написанные только в сценарии A разрешение запросов на выполнение, написанных в соответствии со сценарием B. Теория заключается в том, что сценарий A будет уязвим для внедрения, если базовое приложение не выполнит проверку ввода, что позволит что-то вроде «EXEC spGetUserInfo 42; отбросить базу данных foo; -» для возможного будет выполняться, в то время как сценарий B просто не будет выполнен, когда SqlServer не сможет преобразовать "42; отбросить базу данных foo; -" в целое число.

Можно ли настроить SqlServer так, чтобы он не выполнял хранимые процедуры, вызываемые в соответствии со сценарием A?

Answer 1

Не так далеко, как я знаю, и я очень старался, как это сделать.

Самое близкое, что я могу придумать, - это как-то что-то сделать с сетью, чтобы только RPC-соединения с SQL Server были разрешены, так как вызовы ".StoredProcedure" обычно проходят через RPC, но динамические запросы SQL не могут. Однако я не знаю достаточно об управлении сетью и управлении сервером, чтобы понять, выполнимо ли это.

Другой (и более стандартный) подход заключается в том, чтобы просто предоставить пользователям / приложениям только ПОДКЛЮЧЕНИЕ доступа к вашей базе данных, но не доступ к ЛЮБОМУ из объектов базы данных. Затем создайте хранимые процедуры в их собственной SCHEMA и предоставьте их владельцу / схеме обычный доступ к объектам базы данных (таблицам, представлениям, любым другим хранимым процедурам и т. Д.). Наконец, затем предоставьте пользователям EXECUTE доступ к хранимым процедурам в этой схеме. Это все еще не помешало бы каждому возможному сценарию динамического SQL, но оно устраняет опасность (и смысл большинства из них).

Answer 2

Вероятность того, что ядро ​​базы данных SQL Server никогда не предотвратит это. Причина этого в том, что, насколько SQL Server знает, когда эти команды входят в SQL Server, команды в основном одинаковы. Драйвер на клиентском компьютере выполняет форматирование.

Единственный способ защитить ядро ​​базы данных от SQL-инъекций - это обработать его на уровне приложений.

Answer 3

Отредактировано: я исправлен, вернулся и прочитал стандарт TDS здесь:

http://www.sybase.com/content/1040983/Sybase-tds38-102306.pdf

Команда TDS_LANGUAGE поддерживает собственные параметры по проводам, так что фактически SQL Server получает параметризованные запросы.

Что касается того, есть ли способ принудительно использовать параметры и не принимать аргументы в CommandText, я не знаю, как это сделать.