Доказательство внедрения SQL
Для SQL Server 2005:
select * from sys.dm_os_performance_counters
select * from sys.dm_exec_requests
5 ответов
Chr (8) является частью строки литерала в кавычках, как и оператор обновления, поэтому SQL Server не будет интерпретировать его как вызов функции. В этом примере для Text1 будет установлено буквальное значение:
'Chr(8); update tblMaint SET Value1 = 2 WHERE ValueID = 2--
(да, включая эту одинарную кавычку)
Итак, в этом примере ваш код является безопасным. Большинство проблем с SQL-инъекциями связано с тем, что случайно не удается проверить и процитировать значения; в правильно цитируемом SQL-операторе нет ничего опасного по своей сути.
Ваш метод CleanForSQL обрабатывает только строковые ситуации. Что произойдет, если вы используете не строку, а INT? В этом случае не будет конечного тика для закрытия, поэтому инъекция все равно произойдет. Рассмотрим этот пример ...
Database.DBUpdate("UPDATE tblFilledForms SET Int1 = " + CleanForSQL(txtNote.Text) + " WHERE FilledFormID = " + DGVNotes.SelectedRows(0).Cells("FilledFormID").Value.ToString)
в этом случае достаточно ввести следующее ...
0; update tblMaint SET Value1 = 2 WHERE ValueID = 2 -
У Скотта Айви есть классический случай, который может его нарушить, - отсутствие кавычек, защищающих числовой ввод. (+1)
В зависимости от языка и места «очистки» строки и используемой базы данных ваш непосредственный риск заключается в том, что язык позволяет экранировать строку. В этот момент одинарная кавычка, которую вы пытаетесь избежать, идет не так
\ '; УДАЛИТЬ yourTable; - => \ ''; DROP yourTable; -
Это входит в вашу строку sql как
UPDATE tblFilledForms SET Text1 = '" + \''; DROP yourTable;-- + ' etc.
Что тогда:
UPDATE tblFilledForms SET Text1 = '\''; DROP yourTable;-- ' etc.
'\' 'принимается как буквальная строка одинарной кавычки, если ваша база данных поддерживает экранированные символы - бинго ваш скомпрометированный .
В равной степени необходимо помнить о том, чтобы защита была эффективной, даже если предоставленный пример оператора обновления не смог защитить параметр в предложении where, было ли это потому, что DGVNotes.SelectedRows (0) .Cells ("FilledFormID"). Value.ToString) никогда не мог быть введен пользователем? будет ли это выполняться на протяжении всего срока службы приложения и т. д.?
Вы не делаете ничего плохого. Вот как SQL Server анализирует строки. Первая кавычка открывает строку, затем вы сразу же следили за ней с помощью экранированной кавычки, за которой следует Chr (8).
В качестве упражнения, что произойдет, если вы запустите это в SQL Server: SELECT '' 'Здравствуйте '? В этом случае применяются точно такие же правила синтаксического анализа.
Я думаю, ваша проблема в том, что Chr (8) не выполняется, вам нужно найти другой способ вставить начальную кавычку.