Member 12480887 Ответов: 4

Параметризация вторичных переменных в SQL

Здравствуй У меня есть задача параметризации старого классического веб-приложения ASP. В приложении буквально тысячи строк SQL. Мой вопрос: нужно ли параметризовать вторичные / производные переменные / данные? Например, предположим, что есть форма, которую отправляет пользователь. Очевидно, что все вводимые пользователем данные должны быть параметризованы. Пример: «Вставить в значения Tbl1 (Col1, Col2) (?,?)» Однако на многих страницах приложение вызывает другие данные из базы данных на основе только что захваченных данных формы (то, что я назвал вторичными / производными данными) и затем это используется для обновления / вставки в другие таблицы. Пример: «Выберите Value1, Value2 из Tbl1, где Id = (Выберите Max (Id) из Tbl1)», затем «Вставить в Tbl2 (Col1, Col2) значения (Value1 ?, Value2?)», Где Value1? и Value2? были возвращены оператором select.

Итак, необходимо ли параметризовать вторичные / производные переменные? Я думаю, что это не обязательно, потому что любая SQL-инъекция привела бы к сбою первой SQL-вставки, и поэтому последующие SQL-вызовы не будут выполняться. Это правильно или неправильно?

Что я уже пробовал:

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

Maciej Los

Я не уверен, что хорошо вас понимаю, но ваше замешательство вызвано отсутствием информации о SQL. Я бы предложил использовать только хранимые процедуры.

4 Ответов

Рейтинг:
31

OriginalGriff

В общем, я бы сказал: "Параметризуйте все".
Подумайте об этом: если вы выберете строку, введенную пользователем из БД, она будет иметь тот же риск при объединении в команду INSERT, что и при первом представлении в БД. 

x';DROP TABLES Clients;--
из столбца БД это не делает его менее опасным, чем извлечение его из текстового поля.
Я параметризую значения DATETIME как само собой разумеющееся, чтобы избежать путаницы между различными системными настройками: передача необработанного значения DateTime безопаснее, чем передача "Строковой" версии.
И я параметризую числа, потому что в какой-то момент в будущем они могут быть изменены на числовые, и если это уже параметр, который не вызывает проблем.

С вашим запросом "Insert into Tbl2 (Col1, Col2) values (Value1?, Value2?)" он сохраняется-при условии, что значения никак не объединяются (но обычно лучше использовать INSERT INTO SELECT, а не разделять их:
INSERT INTO Tbl2 (Col1, Col2) SELECT Value1, Value2 FROM Tbl1 WHERE Id=(SELECT MAX(Id) FROM Tbl1)

Рейтинг:
27

Wendelius

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

1. изменения программы, в то время как в самом начале может быть так, что некоторые операторы будут использоваться только внутри программы, Что делать, если дизайн изменится. У вас может быть полностью действительный, многократно используемый оператор, и вы можете использовать его в том месте, где он запускается с прямым вводом пользователем.

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

3. нужно делать преобразования, думать о десятичных дробях, датах, времени, специальных символах, таких как ' и так далее. Вам нужно будет должным образом учитывать все эти аспекты при построении заявления. Например, с моими региональными настройками, если бы я связал десятичное число с инструкцией SQL, это с треском провалилось бы, так как мой разделитель dfor decimals-запятая.

4. повторное использование плана, когда используются параметры, база данных может более легко использовать существующий план выполнения. Если вы используете литералы, базе данных может потребоваться выполнить оптимизацию для каждого оператора отдельно или, по крайней мере, выполнить дополнительную работу, чтобы идентифицировать оператор как существующий при использовании литералов. При более сложных утверждениях количество потраченного времени значительно.

5. повторное использование оператора, если вам нужно выполнить один и тот же оператор несколько раз с разными значениями, вы можете использовать выходящий оператор и объект команды. Просто измените значения параметров и выполните. В противном случае вам нужно будет, по крайней мере, изменить оператор команды, и это повлияет на кэш команд на стороне клиента (если применимо).

Как уже было сказано, есть несколько причин использовать параметры, в то время как я не могу думать о каких-либо преимуществах отказа от использования параметров. Так:

Цитата: Борг[^]
Сопротивление бесполезно. Вы будете ассимилированы.
:)

Рейтинг:
2

Member 12480887

Спасибо OriginalGriff, Mika и Dave за ваш ценный вклад. Я думаю, что нет никакого сорткута! Ну вот...

Рейтинг:
16

Dave Kreskowiak

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

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

Почему бы вам не параметризовать запрос? Я не могу тебе сказать. Я бросил это дерьмо очень давно.

Richard Deeming

Конечно, вы имеете в виду, что это "нет только для предотвращения" SQLi?

И если вы сделаете это правильно, параметризованные запросы предотвратят появление SQLi все случаи.

Dave Kreskowiak

"Если" :)