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

Ответ 1

Да, есть. Выдержка из Wikipedia

"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-инъекция - не простая атака для борьбы. Я бы сделал очень тщательное исследование, если бы был вами.

Ответ 2

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

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

Ответ 3

Да, это окончательно возможно.

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

SELECT * FROM thingy WHERE attributeID =

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

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

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

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

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

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

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

/Вея

Ответ 4

Я предлагаю вам передать переменные в качестве параметров, а не создавать собственный 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"));

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

Вам также может понадобиться рассмотреть этот fooobar.com/questions/161689/....

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

Это зависит от того, как вы собрали запрос, но по сути да.

Например, на Java, если вы должны это сделать (преднамеренно вопиющий пример):

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

тогда у вас есть хороший шанс, что вы открываете себе атаку инъекций.

В Java есть некоторые полезные инструменты для защиты от них, такие как PreparedStatements (где вы передаете строку типа "SELECT name_" из Customer WHERE ID =? ", а уровень JDBC обрабатывает экраны при замене" токенов "для вас), но некоторые другие языки не так полезны для этого.

Ответ 12

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

\;.*--\

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

Поэтому ответ: Нет, просто удаление апострофов не гарантирует безопасность SQL-инъекции.

Ответ 13

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

Ответ 14

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

Если вы когда-либо получали id = "привет", когда вы ожидали id = 1044, всегда лучше возвращать пользователю полезную ошибку, а не позволять базе данных возвращать ошибку.