От чего вас защищают параметры sql?

Question

Параметры используются для защиты вас от злонамеренного ввода пользователя.

Но если параметр ожидает строку, возможно ли записать ввод, который будет интерпретирован как sql, чтобы злоумышленники могли использовать такие вещи, как «DROP», «TRUNCATE» и т. Д.

Есть ли различия в защите между параметрами в asp, asp.net, java и других?

---

См. Также: Достаточно ли параметров для предотвращения SQL-инъекций?

Answer 1

Параметризованные запросы обычно заключают в кавычки параметр, если это строка позади сцены, чтобы обычные операторы SQL не интерпретировались как таковые. Это означает, что даже если пользователь вводит потенциально вредоносные данные, он просто рассматривается как строковый ввод и не интерпретируется как операторы / команды SQL.

Могут быть технические различия в том, как это реализовано в различных платформах, но основная идея (и результат) одинаковы.

Answer 2

Вы должны быть осторожны с вашими определениями. «Параметры» могут означать несколько вещей; Например, параметры хранимой процедуры не защищают вас сами по себе. Чтобы использовать Java в качестве примера:

sql = "exec proc_SearchForUser '" + userNameToSearch + "'";

не лучше и не хуже сырых

sql = "SELECT * FROM Users WHERE userName = '" + userNameToSearch + "'";

и так же восприимчив к имени пользователя

';DROP TABLE users;--

Параметризованные запросы, с другой стороны, безопасны. Они могут выглядеть как

PreparedStatement statement = con.prepareStatement("SELECT * FROM Users WHERE userName = ?");

или действительно

PreparedStatement statement = con.prepareStatement("exec proc_SearchForUser ?");

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

statement.setString(1, userName);

тогда строка - даже такая, как "'; DROP TABLE users; -" - будет должным образом экранирована ядром БД и будет обезврежена.

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

Answer 3

Ничто из того, что вы вводите в качестве параметра с помощью вызова BindWhwhat (), не может быть выполнено как SQL.

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

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

Таким образом, вам все равно нужно убрать ввод (или хотя бы экранировать) любые символы ({[]}) \ type;

Answer 4

Нет. Атаки SQL-инъекции могут происходить с любого языка в любой БД SQL. Тип атаки, на которую вы ссылаетесь, - это когда программист использует в своем источнике динамический SQL, такой как «USER_NAME = sName», и пользователь может ввести неограниченное количество текста для имени пользователя, чтобы он мог добавить комментарий и затем ввести любые новые операторы SQL, такие как « DROP ',' TRUNCATE 'и т. Д.

Answer 5

Единственный риск будет, если вы выполните exec для параметризованной строки.

Во всех остальных случаях параметризованные запросы безопасны.

Answer 6

Не как параметр. Инъекция SQL основана на объединении вредоносного кода в строку SQL и выполнении оператора SQL из этой строки. Готовое утверждение принимает параметры независимо от содержимого. С подготовленным оператором фактический текст самого оператора SQL никогда не изменяется.