Я бы добавил в список Томалаков еще один пункт.
Избегайте использования конкатенации значений полей в коде SQL. То есть в некоторых случаях хранимая процедура может построить некоторый SQL в строке для последующего выполнения. Это хорошо, если только текстовое поле не используется как часть его конструкции.
Параметр команды может защитить код SQL, предназначенный для ввода значения от перехвата, при выполнении нежелательного SQL, но он позволяет такому нежелательному SQL стать данными в базе данных. Это уязвимость первого уровня. Уязвимость внедрения второго уровня существует, если значение поля затем используется в некоторой конкатенации строк SQL внутри хранимой процедуры.
Еще одним соображением является то, что это просто минимальная защита. Все, что он делает, это делает попытки атаки безвредными. Однако во многих случаях может быть лучше добавить к этому систему, которая предотвращает такой ввод данных в целом и / или изменяет администраторов для потенциальной атаки с использованием инъекций.
Именно здесь проверка ввода становится важной. Я не знаю ни одного инструмента, который бы сделал это для вас, но несколько простых регулярных выражений могут помочь. Например, «<\ w +» обнаружит попытку включить тег HTML в поле. </p>