Является ли это восприимчивым к инъекционной атаке

Question

Является ли это восприимчивым к инъекционной атаке

1

Является ли следующий фрагмент С# восприимчивым к SQL Injection Attack?

string sql = @"
    declare @sql navarchar(200)
    set @sql = 'select * from customers where customerId = ' + convert(navarchar, @custId)
    exec sp_sqlexec @sql
"

oSQL.Parameters.Add("custId", CustomerId);
DataTable dt = oSQL.ExecuteDataTable(sql);

Я понимаю, что это тривиальный оператор sql, но меня больше интересует подход использования exec sp_sqlexec. Заявление sql более динамично, чем указано, но не думаю, что это важно для моего вопроса.

Rod 10 дек. 2014, в 00:19

Источник

3

Если CustomerId - это строка, которую пользователь может ввести, тогда yes. Если это число, то нет. В любом случае, почему вы используете динамический SQL? Вы можете просто выполнить этот SQL напрямую.
D Stanley 09 дек. 2014, в 22:41
0

Хотя @DStanley технически верен, главное здесь (по крайней мере для меня) заключается в том, что этот базовый подход широко открыт для внедрения SQL. На SO есть масса информации об этом.
Andrew 09 дек. 2014, в 22:43
0

Извините, я хочу уточнить в OP ... Я знаю, что это тривиальное утверждение, но я собирался получить больше концепции запуска sp_sqlexec с параметризованным запросом. Конечно, оператор Sql более динамичен, чем этот оператор.
Rod 09 дек. 2014, в 22:45
0

Это возможно. Я предлагаю лучше подумать о наличии ORM для выполнения запросов. Поскольку у вас есть это прямо сейчас, вам придется проверить этот параметр custID.
Camilo Aguilar 09 дек. 2014, в 22:46
0

sp_sqlexec даже не поддерживается системной процедурой до SQL 2005
EkoostikMartin 09 дек. 2014, в 22:50
0

@EkoostikMartin, я не понимаю причину вашего комментария (извинения)
Rod 09 дек. 2014, в 22:52
0

также увидеть это
Beth 09 дек. 2014, в 22:55

Показать ещё 5 комментариев

Теги:

sql-server

c#

2 ответа

2

Обновление ответа на основе комментариев от SO. Динамический SQL (или действительно любой оператор SQL, это хорошее правило для соблюдения), как правило, обычно открыт для SQL Injection, если их потенциал для ввода пользователем. Если все ваши параметры, которые делают учетную запись SQL, говорят, поступают из другой базы данных или говорят о выпадающем списке и т.д., Тогда нет, это не вписывается в SQL Injection.

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

logixologist 09 дек. 2014, в 19:56

Ещё вопросы

Если CustomerId - это строка, которую пользователь может ввести, тогда yes. Если это число, то нет. В любом случае, почему вы используете динамический SQL? Вы можете просто выполнить этот SQL напрямую.
Хотя @DStanley технически верен, главное здесь (по крайней мере для меня) заключается в том, что этот базовый подход широко открыт для внедрения SQL. На SO есть масса информации об этом.
Извините, я хочу уточнить в OP ... Я знаю, что это тривиальное утверждение, но я собирался получить больше концепции запуска sp_sqlexec с параметризованным запросом. Конечно, оператор Sql более динамичен, чем этот оператор.
Это возможно. Я предлагаю лучше подумать о наличии ORM для выполнения запросов. Поскольку у вас есть это прямо сейчас, вам придется проверить этот параметр custID.
sp_sqlexec даже не поддерживается системной процедурой до SQL 2005
@EkoostikMartin, я не понимаю причину вашего комментария (извинения)

D Stanley · Accepted Answer · 2014-12-09T20-20-00.000Z

Несколько более безопасным решением было бы сделать так, чтобы параметр dynaimc был параметризован:

(Обратите внимание, что вы также должны использовать sp_executesql:

string sql = @"
    declare @sql navarchar(200)
    set @sql = 'select * from customers where customerId = @customerId'
    exec sp_sqlexecuseSQL @sql, N'@customerId INT', @customerId = @custId
"

oSQL.Parameters.Add("custId", CustomerId);
DataTable dt = oSQL.ExecuteDataTable(sql);