Является ли этот метод построения динамического SQL уязвимым для SQL-инъекций или плохим для производительности?

Question

Я хотел бы создать безопасный динамический оператор выбора, который может обрабатывать несколько предложений WHERE.

Например, базовый SQL будет выглядеть так:

SELECT * FROM Books Where Type='Novel'

Я бы передал функцию что-то вроде:

SafeDynamicSQL("author,=,Herman Melville","pages,>,1000");

Что бы очистить входные данные и объединить как:

SELECT * FROM Books Where Type='Novel' AND author=@author AND pages>@pages

Функция будет очищать имя столбца, проверяя массив предопределенных имен столбцов. Оператору будет разрешено быть только>, <, =. Значение будет добавлено как обычный параметр. </p>

Будет ли это уязвимо для SQL-инъекций?

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

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

Answer 1

Похоже, что вы заново изобретаете любое количество существующих решений ORM, которые предлагают аналогичный API для создания предложений WHERE.

Ответ на ваш вопрос зависит от того, что вы подразумеваете под "Значение будет добавлено какнормальный параматер. "Если под этим вы подразумеваете выполнение конкатенации строк для получения строки, которую вы показали, то да, это все равно будет подвергаться атаке SQL-инъекций.Если вы имеете в виду использование фактического параметризованного запроса, тогда вы будете в безопасности.В последнем случае вы должны создать что-то вроде

 SELECT * FROM Books Where Type='Novel' AND author=? AND pages > ?

и затем связать это со списком значений, таких как ['Herman Melville', 1000].Как именно это будет выглядеть, зависит от того, какой язык программирования вы используете.

Наконец, если вы пойдете по этому пути, я настоятельно рекомендую перейти от аргументов, разделенных запятыми, к трем отдельным аргументам, и вы сохраните себемного времени программирования.

Answer 2

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