Может ли атака SQL Injection выполняться через что-либо, кроме SqlCommand?

Если у меня есть веб-приложение ASP.NET, имеющее базу данных SQL Server, можно ли предположить, что если атака SQL Injection будет выполнена, она пройдет через экземпляр класса SqlCommand?

Фон:

Я в ситуации, когда унаследовал довольно большое веб-приложение с некоторыми уязвимостями SQL Injection. Я нашел несколько, просто просмотрев код для других проблем, но мне интересно, можно ли безопасно найти все уязвимости SQL Injection, чтобы искать все файлы для экземпляров SqlCommand, а затем проверить, не параметризированы ли они запросы. Является ли это прочным планом?

Ответ 1

Я бы не выглядел просто для SqlCommand специально - код мог использовать DBCommand или IDbCommand. Его можно обернуть в ORM, например EF, L2S или NHibernate (все предлагают некоторый уровень доступа к сыру). Он может использовать что-то вроде "dapper" или simple.data. Или DataTable/DataAdapter. У вас может быть код, который использует устаревший доступ OLEDB или ADODB. Черт, для всех, кого мы знаем, вы могли бы написать свой собственный низкоуровневый TDS API.

Итак: это сводится к проверке кода доступа к данным, который может принимать различные формы. Если ваш ведомственный подход "напрямую использует SqlCommand", то это меняет ситуацию.

Кроме того: SQL-инъекция не ограничивается .NET - вы можете, например, создать риск инъекции SQL в исходном текстовом тексте или хранимой процедуре , даже если вы параметризуете, если TSQL любой тип конкатенации для создания динамического SQL, который вызывается через EXEC. Обратите внимание, что sp_executesql может помочь с этим.

Ответ 2

В зависимости от вашей схемы базы данных вам также может потребоваться проверить наличие атак в хранимых procs (при условии, что вы используете хранимые procs). Я видел, как люди использовали в своем коде хранимые процедуры с параметрами, но в proc они просто используют EXEC для запроса:

CREATE PROC Dummy
(
   @Str VARCHAR(50)
)
AS
EXEC ('SELECT * FROM Table Where Column = ''' + @Str + '''')

Ответ 3

Вам также нужно будет искать вещи, которые используют или содержат SqlCommand. К ним относятся, помимо прочего, SqlDataAdapter.

Ответ 4

Просто потому, что вы используете параметризованную библиотеку запросов, это не значит, что она используется правильно. При проверке кода я видел случаи, когда используются параметризованные запросы, но некоторые части запроса все еще построены с использованием конкатенации строк. Более конкретно, имя таблицы и часть ограничения/порядка запроса являются общими ошибками.

Если вы полностью настроены на статический анализ, лучшим вариантом будет grep для всех запросов в приложении, а затем убедитесь, что каждый из них построен правильно. Да, это займет много времени, и это может быть ошеломляющим. Сделайте перерывы, сделайте заметки и нажмите. Когда вы найдете инъекцию sql, это будет полезно!