Вам не нужно вводить пользователя, чтобы перенести атаку SQL-инъекцией.
Допустим, у вас есть страница продукта, которая вызывается с помощью URL-адреса, такого как:
product.aspx?ID=123
И в вашем коде у вас есть такой запрос:
string sql = "SELECT * FROM Products WHERE ID = " + Request.Querystring["ID"];
Кто-то может вызвать вашу страницу с этим URL:
product.aspx?ID=123;DROP Table Students;
И бац, ты только что был.
В дополнение ко всему, что может быть передано через пользователя, строку запроса, сообщение, cookie, переменную браузера и т. Д. Я думаю, что это хорошая практика - всегда использовать параметры, даже если в вашем коде есть литералы. Например:
if(SomeCondition)
{
sql = "Select * from myTable where someCol = 'foo'";
}
else
{
sql = "Select * from myTable where someCol = 'bar'";
}
это может быть безопасно для инъекций, но ваша СУБД будет кэшировать их как два разных запроса.
если ты изменишь это на следующее:
sql = "Select * from myTable where someCol = @myParam";
if(SomeCondition)
{
myCommand.Parameters.Add("@myParam").value = "foo";
}
else
{
myCommand.Parameters.Add("@myParam").value = "bar";
}
Вы получаете тот же результат, но СУБД будет кэшировать его только как один запрос, подставляя параметр во время выполнения. Я использую это как практическое правило, чтобы ВСЕГДА использовать параметризованные запросы, просто для обеспечения согласованности, не говоря уже о небольшом улучшении кэша.