Есть ли способ ввести SQL, даже если символ 'удален?

Question

Если из запроса SQL я удаляю все символы ', есть ли другой способ выполнить атаку SQL-инъекцией на базу данных?

Как это можно сделать? Кто-нибудь может привести примеры?

Answer 1

Да, есть. Отрывок из Википедии

"SELECT * FROM data WHERE id = " + a_variable + ";"

Из этого утверждения ясно, что автор предполагал, что a_variable является числом, соответствующим полю "id". Однако, если это на самом деле строка, то конечный пользователь может манипулировать оператором по своему выбору, тем самым обходя необходимость в escape-символах. Например, установив a_variable в значение

1;DROP TABLE users

удалит (удалит) таблицу "users" из базы данных, поскольку SQL будет отображаться следующим образом:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

SQL-инъекция не простая атака для боя. Я бы провел очень тщательное исследование на вашем месте.

Answer 2

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

См. WikiPedia для образцов для профилактики.

Answer 3

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

Код, который вы создаете, выглядит примерно так:

' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

Если у вас есть имя, похожее на мое, с 'в нем. Очень неприятно, что все '-символы удалены или помечены как недействительные.

Вы также можете посмотреть на этот вопрос Stackoverflow о SQL-инъекциях .

Answer 4

Да, это возможно.

Если у вас есть форма, где вы ожидаете, что целое число сделает ваш следующий оператор SELECT, вы можете ввести что-нибудь подобное:

SELECT * FROM thingy WHERE attributeID =

• 5 (хороший ответ, без проблем)
• 5; DROP стол users; (плохо, плохо, плохо ...)

На следующем веб-сайте подробно описаны классические методы SQL-инъекций: Шпаргалка SQL-инъекций .

Использование параметризованных запросов или хранимых процедур не лучше. Это просто готовые запросы с использованием переданных параметров, которые также могут быть источником внедрения. На этой странице также описано: Атака хранимых процедур в SQL .

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

Как всегда, не доверяйте данным, поступающим извне. Фильтруйте их на этих 3 уровнях:

• Уровень интерфейса для очевидных вещей (выпадающий список выбора лучше, чем свободное текстовое поле)
• Логический уровень для проверок, связанных с характером данных (int, string, length), разрешениями (может ли этот тип данных использоваться этим пользователем на этой странице) ...
• Уровень доступа к базе данных (экранирование простой кавычкой ...).

Получайте удовольствие и не забудьте проверить WikiPedia для ответов.

/ Вея

Answer 5

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

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

Answer 6

Поскольку это относительно старый вопрос, я не буду писать полный и исчерпывающий ответ, так как большинство аспектов этого ответа были упомянуты тем или иным постером.
Однако я считаю необходимым поднять еще одну проблему, которая не была затронута никем здесь - SQL Smuggling. В определенных ситуациях возможно «переправить» символ кавычки 'в ваш запрос , даже если вы пытались удалить его . На самом деле это может быть возможно, даже если вы использовали правильные команды, параметры, хранимые процедуры и т. Д.

Ознакомьтесь с полным текстом исследования на http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (раскрытие, я был основным исследователем в этом вопросе) или просто Google "SQL Smuggling".

Answer 7

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

Но параметризованные запросы / хранимые процедуры намного лучше.

Answer 8

. , , э-э, около 50000000 других способов

может быть что-то вроде 5; drop table employees; --

В результате sql может быть что-то вроде: select * from somewhere where number = 5; drop table employees; -- and sadfsf

(-- начинает комментарий)

Answer 9

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

Answer 10

Да, абсолютно: в зависимости от вашего диалекта SQL и тому подобного, есть много способов добиться внедрения, которые не используют апостроф.

Единственная надежная защита от атак с использованием SQL-инъекций - это использование параметризованной поддержки операторов SQL, предоставляемой вашим интерфейсом базы данных.