Использует ли параметризованный SqlCommand мою программу невосприимчив к SQL-инъекции?

Я знаю, что SQL-инъекция довольно опасна. Теперь в моем коде С# я компилирую параметризованные запросы SqlCommand class:

SqlCommand command = ...;
command.CommandText = "SELECT * FROM Jobs WHERE JobId = @JobId;";
command.Parameters.Add("@JobId", SqlDbType.UniqueIdentifier ).Value = actualGuid;
command.ExecuteNonQuery();

Будет ли это сделать мой код невосприимчивым к SQL-инъекции? Нужно ли мне что-то делать?

Ответы

Ответ 1

Я бы сказал, для вашего конкретного и, вероятно, канонического примера для параметризованных запросов, да, этого достаточно.

Однако люди иногда пишут такой код

cmd.CommandText = string.Format("SELECT * FROM {0} WHERE col = @col;", tableName);
cmd.Parameters.Add("@col", ...);

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

Ответ 2

В соответствии с примечанием к этой статье MSDN "Специальные символы ввода представляют угрозу только с динамическим SQL, а не при использовании параметризованного SQL".

Поэтому я считаю, что вы в безопасности от SQL Injection. Могут быть некоторые логические риски при использовании идентификаторов, таких как значения Idendity в ваших URL-адресах, но это еще одна история.

Ответ 3

SQL Injection в основном зависит от выполнения динамического SQL. Другими словами, операторы SQL, построенные путем конкатенации SQL с введенными пользователем значениями.

Чтобы полностью исключить SQL Injection,

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

Из MSDN

Ответ 4

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

Ответ 5

Вы не защищены от SQL-инъекций, если используете динамический sql, даже если вы передаете его через параметры. Слишком плохо SQL Server не имеет встроенной функции для дезинфекции параметров