Там некоторый путь состоит в том, чтобы ввести SQL, даже если 'символ удален?

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

... мм приблизительно 50 000 000 других путей

, возможно, что-то как 5; drop table employees; --

получающийся sql могут быть чем-то как: select * from somewhere where number = 5; drop table employees; -- and sadfsf

(-- запускает комментарий)

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

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

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

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

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

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

Я предлагаю, чтобы Вы передали переменные как параметры и не создали Ваш собственный 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 .

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

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

ВЫБОР * ОТ thingy, ГДЕ attributeID =

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

следующий веб-сайт детализирует дальнейшую классическую технику Внедрения SQL: шпаргалка Внедрения SQL .

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

Теперь, если Вы подавляете простую кавычку, Вы предотвращаете только данный набор нападения. Но не все они.

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

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

Весело проводят время и не забывают проверять Википедия для ответов.

/Vey

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

См. Википедия для образцов предотвращения.

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

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

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

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

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

Это зависит от того, как Вы соединяете запрос, но в сущности да.

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

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

тогда существует хороший шанс, который Вы открываете сами до инжекционного нападения.

Java имеет некоторые полезные инструменты для защиты от них, таких как PreparedStatements (куда Вы передаете в строке как "ВЫБОР name_ от Клиента ГДЕ идентификатор =?" и уровень JDBC обрабатывает Escape при замене? маркеры для Вас), но некоторые другие языки не так полезны для этого.

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

\;.*--\

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

Поэтому ответ: Нет, просто удаление апострофов не гарантирует Вам безопасности от Внедрения SQL.