Разбор T-SQL для параметризации запроса

Question

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

SELECT field1, field2, field3 FROM tablename WHERE foo=1 AND bar="baz"

и превратить его в нечто вроде этого:

SELECT field1, field2, field3 FROM tablename WHERE foo=@p1 AND bar=@p2 blah blah blah

Что-нибудь уже написано, что выполнит это для меня в c # или vb.net? Это задуман как пробел перед рефакторингом DAL для этого проекта.

ОБНОВЛЕНИЕ: Ребята У меня есть огромное приложение, которое было перенесено с Classic ASP на ASP.NET с буквально тысячами строк встроенного SQL. Единственным преимуществом сохранения является то, что все сгенерированные sql передаются в класс выполнения данных. Я хочу захватить sql перед выполнением и параметризовать их на лету, чтобы остановить переписывание всего приложения.

Answer 1

Не делай этого. Это слишком много работы. Кроме того, при таком подходе существует множество угроз безопасности.

Просмотр объектов Command и параметризованных запросов, как минимум.

Вот небольшой учебник.

Answer 2

Рефакторинг сейчас.

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

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

Зачем создавать значительный фрагмент одноразового кода, который будет трудно отлаживать и который на самом деле не соответствует тому, как вы хотите, чтобы конечная архитектура выглядела?

Answer 3

Рассматривали ли вы запуск регулярного выражения замещения для старого кода? Нечто, извлекающее значения из текущих запросов, заменяющее их параметрами и добавляющее после строки запроса вызов Command.Parameters.AddWithValue (paramName, paramValue), возможно, если все текущие встроенные SQL-выражения следуют одному и тому же значению (или если почти все они делают, и вы можете исправить остаток в вашем любимом редакторе).

Answer 4

Я могу думать только об одном преимуществе, которое принесет параметризация запросов на лету: это уменьшит текущую уязвимость вашего приложения к атакам с использованием SQL-инъекций. В любом случае, лучшее, на что вы могли бы надеяться, это то, что этот гипотетический синтаксический анализатор / интерпретатор на лету ничего не сломал.

Даже если вам не нужно было писать такие вещи самостоятельно (и я готов поспорить, что вы это делаете), это довольно значительный риск для внедрения в производственную систему, тем более что это временная мера, которая будет отброшена при рефакторинге приложение. Достаточно ли высок риск атаки SQL-инъекцией, чтобы это оправдать?

Answer 5

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

Удачи!

Answer 6

Я бы поддержал предложение использовать параметры Command, чтобы делать то, что вы хотите. Любой вид разбора строки SQL-запроса просто просит кого-то поиграть с вами в игру SQL-инъекции. Пример кода ниже. Коллекцией параметров легко манипулировать обычным способом

command.CommandText = "SELECT * FROM table WHERE key_field='?'"
command.Parameters.Append command.CreateParameter(, 8, , , "value") '8 is adBSTR value
set rsTemp = command.Execute