Является ли динамический SQL более уязвимым для внедрения или взлома SQL?

Question

Является ли динамический SQL более уязвимым для SQL-инъекций / взлома? Если да, как предотвратить?

Answer 1

Если вы используете параметры вместо конкатенации строк для указания критериев фильтра, он не должен быть уязвимым для внедрения Sql.

Например:

сделать это:

string sqlQuery = "SELECT * FROM Persons WHERE Persons.Name LIKE @name";

SqlCommand cmd = new SqlCommand ( sqlQuery );
...
cmd.Parameters.Add ("@name", SqlDbType.VarChar).Value = aName + "%";

вместо этого:

   string sqlQuery = "SELECT * FROM Persons WHERE Persons.Name LIKE \'" + aName + "%\'";

Первый пример не уязвим для внедрения SQL, но второй пример очень уязвим.

То же самое относится к динамическому SQL, который вы используете, например, в хранимых процедурах. Там вы можете создать динамический SQL-оператор, который также использует параметры; Затем вы должны выполнить динамический оператор, используя sp_executesql, который позволяет указывать параметры.

Answer 2

Внутри TSQL вы должны использовать sp_ExecuteSql для выполнения любых необходимых вам динамических команд (например, для обеспечения гибкого поиска / сортировки).

Обратите внимание, что если вы не перепрыгнете через несколько обручей с сертификатами, вам все равно потребуется прямое SELECT (и т. Д.) Разрешение на таблицу (в отличие от SPROC, который может предоставлять доступ неявно), но он должен быть безопасным для инъекций. Например:

DECLARE @command nvarchar(4000), @name varchar(50)

SELECT @command = 'SELECT * FROM [CUSTOMER] WHERE [Name] = @Name',
       @name = 'Fred'

EXEC sp_ExecuteSql @command, N'@Name varchar(50)', @name

Очевидно, что в приведенном выше описании нет необходимости использовать динамический SQL - это только для иллюстрации! В основном это полезно, когда (внутри SPROC) у вас есть несколько необязательных условий поиска или гибкое предложение ORDER BY.

В клиентах, отличных от TSQL, вы можете сделать то же самое с параметрами команды.

Также обратите внимание, что sp_ExecuteSql также использует кэш процедур, поэтому может быть более эффективным, чем raw EXEC (@command).

Answer 3

Быстрый ответ - да, если вы строите Sql на лету в вашем приложении, вы должны знать о каждой маленькой уловке, которую попробуют мошенники. Когда вы используете хранимые процедуры, большинство поставщиков позаботятся о них.

Хороший способ уменьшить вероятность внедрения SQL-кода - использовать запросы параметров, как указано выше, если это не подходит, убедитесь, что любое сгенерированное пользователем поле не содержит буквенных символов. Убирайте кавычки, точки с запятой и т. Д. Также убедитесь, что у вашего соединения достаточно доступа только для того, чтобы делать то, что ему нужно, если вы только запрашиваете данные, а затем создайте группу пользователей / безопасности, которая позволяет только выбирать, а не обновлять и особенно удалять. Хорошей практикой также может быть запись sql в журнал - таким образом, вы будете знать, что делают люди, и вы можете настраивать и обнаруживать попытки внедрения.

Answer 4

Это зависит от того, насколько динамичен ваш запрос.

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

Если вы имеете в виду построение запросов в соответствии с динамическими критериями, то у вас могут быть проблемы: -)

Скажем, например, что у вас есть строковый словарь полей для обновления в качестве ключа и новое значение в качестве элемента. Затем вы можете динамически построить запрос на обновление, используя словарь. Теперь, если хакеру удастся изменить одно из имен ваших полей, он может вставить собственный запрос и таким образом взломать вашу систему.

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

Посмотрите здесь интересную дискуссию на эту тему .