Создание безопасных условий поиска для предложения SQL WHERE

Question

Мне нужно создать условия поиска для использования с предложением WHERE. Это условие поиска затем передается другому приложению для выполнения как часть запроса SQL. Поскольку условия поиска могут быть довольно сложными (включая подзапросы), я не верю, что принимающее приложение может их разумно проанализировать, чтобы предотвратить атаки SQL-инъекций.

В соответствии с передовой практикой следует использовать параметризованные запросы. Это прекрасно работает, когда вы используете командный объект для выполнения запроса самостоятельно. В моем случае я хочу получить эту строку запроса с параметрами, слитыми в нее, и разобрать, где интересующее меня условие поиска. Есть ли способ сделать это?

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

Answer 1

Посмотрите на эти 2 ссылки

Этот код предотвращает внедрение SQL?

и

Проверка SQL-инъекции

Answer 2

I думаю у вас все хорошо: согласно электронной документации по SQL Server , одиночная одиночная кавычка, похоже, является единственным способом выхода строки в кавычках это было начато с одной цитаты. Таким образом, замены ' на '' должно быть достаточно, чтобы избежать внедрения SQL через string переменных.

Я не могу придумать, как внедрить SQL через другие, нестроковые собственные типы данных C #, если они правильно (инвариантные по языку) преобразованы в строки.

Тем не менее, параметризованные запросы являются «рекомендуемым» решением. На данный момент ваше приложение выглядит так:

1. Часть A создает инструкцию WHERE на основе пользовательского ввода.
2. Строка, содержащая этот оператор WHERE, передается в часть B.
3. Часть B добавляет SELECT и т. Д. И отправляет его на SQL Server.

Будет ли вариант переписать ваше приложение следующим образом?

1. Часть A создает параметризованный оператор WHERE плюс набор параметров на основе пользовательского ввода.
2. Строка, содержащая инструкцию WHERE плюс Hashtable (или что-то подобное), содержащее параметры, передается в часть B.
3. Часть B создает команду, добавляет SELECT и т. Д., Добавляет параметры и отправляет ее на SQL Server.

Я был в подобной ситуации и решил ее, создав класс SubSQL, который в основном содержит параметризованную строку с CommandText и хэш-таблицу с параметрами. Затем вы можете использовать это как mySubSQL.CommandText += ..., mySubSQL.Parameters("@myfield") = myValue и mySubSQL.MergeInto(myCommand) (реализация должна быть очевидной и простой).

Answer 3

некоторые рекомендации от OWASP