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

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

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

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

5 ответов


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

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

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

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


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

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


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

чтобы полностью избежать SQL-инъекции,

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

с MSDN


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


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