Как предотвратить операторы SQL от внедрения SQL при использовании CLR / C ++ с несколькими переменными?

Question

У меня есть серьезная проблема, когда я не знаю, как предотвратить SQL внедрение при написании SQL операторов в CLR / C ++. Ниже приведен код

String^ sqlstr = "SELECT * FROM ";
sqlstr += tableName + " WHERE " + field + " = " + fieldEntity;

. Мне нужно, чтобы я мог правильный ввод SQL Предотвращение инъекций к этому утверждению.

Фоновый код

class database
{
protected:
    string fieldEntity;
    string tableName;
    string field;
...
____
OleDbDataReader^ openData(String^ fieldEntity, String^ field, String^ tableName)
    {

        String^ sqlstr = "SELECT * FROM ";
        sqlstr += tableName + " WHERE " + field + " = " + fieldEntity;
...
___
OleDbDataReader^ reader2 = testData.openData(effectID, "effectID", "effectOnUser");
    while (reader2->Read())
    {
        Object^ dHealthptr = reader2["effectOnHealth"];
        Object^ dTirednessptr = reader2["effectOnTiredness"];
        Object^ dHappinessptr = reader2["effectOnHappiness"];
...

Answer 1

Существует два способа предотвращения SQL Инъекции, и среда SQLCLR не меняет этого:

1. Предпочтительным механизмом является использование параметризованных запросов. Разные языки и библиотеки go говорят об этом по-разному, но, по крайней мере, вы должны иметь возможность использовать подготовленные утверждения. Обратите внимание, что это не относится к сценарию ios, который не может принять переменную, например, с tableName и field в вашем коде.
   Пожалуйста, см .:
   1. Выпуск параметризованного запроса
   2. Использование хранимых процедур

2. Санация входных данных:

   1. Обнаженный минимум и, безусловно, самое распространенное требование - избегать одинарных кавычек, удваивая их (т.е. ' становится '')

   2. Дополнительно (ниже приводится цитата из мой ответ на DBA.StackExchange):

      Существует менее известный тип атаки, при котором злоумышленник пытается заполнить поле ввода апострофами, так что строка внутри хранимой процедуры, которая будет использоваться для построения Dynami c SQL, но который объявлен слишком маленьким, не может вместить все и выталкивает конечный апостроф и каким-то образом заканчивается правильным количеством апострофов, чтобы больше не "сбегать" внутри строка. Это называется SQL Усечение; о нем говорилось в статье журнала MSDN под названием «Новые SQL Усечения обрезания и как их избежать», написанной Бала Нирумаллой, но эта статья больше не находится в сети. Выпуск, содержащий эту статью - выпуск журнала MSDN от за ноябрь 2006 г. - доступен только в виде файла справки Windows (в формате .chm ). Если вы загрузите его, он может не открыться из-за настроек безопасности по умолчанию. Если это произойдет, щелкните правой кнопкой мыши файл MSDNMagazineNovember2006en-us.chm и выберите «Свойства». На одной из этих вкладок будет опция «Доверять этому типу файла» (или что-то в этом роде), которую необходимо проверить / включить. Нажмите кнопку «ОК» и попробуйте снова открыть файл .chm .

      Итак, убедитесь, что вы правильно изменили размер входных параметров строки. Вам не нужно VARCHAR(500) для столбца, который объявлен как VARCHAR(25). Пожалуйста, смотрите мой ответ на DBA.StackExchange для более подробной информации и примеров: Почему SQL Инъекция не происходит по этому запросу внутри хранимой процедуры?

Answer 2

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

Для другой переменной fieldEntity, я полагаю, это следует использовать как постоянное значение в вашем запросе SQL. Вы можете защитить это от внедрения SQL с помощью параметра запроса.

Я не знаю CLR, но существует множество примеров использования SQL параметров запроса в C ++ или C#. * 1008. *

• https://owasp.org/www-project-cheat-sheets/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html