Я могу защитить от Внедрения SQL путем выхода из одинарной кавычки и окружающего ввода данных пользователем с одинарными кавычками?
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
17 ответов
В первую очередь, это - просто плохая практика. Контроль ввода всегда необходим, но это также всегда сомнительно.
Хуже все же, проверка черного списка всегда проблематична, намного лучше явно и строго определить то, что оценивает/форматирует Вас, принимают. По общему признанию это не всегда возможно - но в некоторой степени это должно всегда делаться.
Некоторые научно-исследовательские работы на предмете:
- http://www.imperva.com/docs/WP_SQL_Injection_Protection_LK.pdf
- http://www.it-docs.net/ddata/4954.pdf (Раскрытие, это последнее было моим ;))
- https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf (на основе предыдущей бумаги, которая больше не доступна)
Точка, любой черный список, который Вы делаете (и также разрешающие белые списки) может быть обойден. Последняя ссылка на мою статью показывает ситуации, где даже заключают выход в кавычки, может быть обойден.
, Даже если эти ситуации не относятся к Вам, это - все еще плохая идея. Кроме того, если Ваше приложение не является тривиально небольшим, Вы оказываетесь перед необходимостью иметь дело с обслуживанием и возможно определенным количеством управления: как Вы удостоверяетесь что его сделанный правильно, везде все время?
надлежащий способ сделать это:
- проверка Белого списка: тип, длина, формат или принятые значения
- , Если Вы хотите поместить в черный список, идет прямо вперед. Выход кавычки хорош, но в контексте другого смягчения.
- Объекты команды Использования и Объекты параметра, чтобы предварительно проанализировать и проверить
- параметризированные запросы Вызова только.
- Еще лучше, используйте Хранимые процедуры исключительно.
- Избегают использования динамического SQL и не используют конкатенацию строк для создания запросов.
- При использовании SPS, можно также ограничить полномочия в базе данных к выполнению необходимого SPS только и не таблиц доступа непосредственно.
- можно также легко проверить, что вся кодовая база только получает доступ к DB через SPS
В то время как Вы могли бы найти решение, которое работает на строки на числовые предикаты, необходимо ли также удостовериться, что они являются только передающими в числах (простая проверка является банкой оно быть проанализированной как международная/двойная/десятичная?).
Это - большая дополнительная работа.
Вместо того, чтобы изменять одинарную кавычку на (что похоже) две одинарных кавычки, почему не только изменяют его на апостроф, кавычку, или удаляют его полностью?
Так или иначе, это - что-то вроде клуджа... особенно, когда у Вас законно есть вещи (как имена), который может использовать одинарные кавычки...
ПРИМЕЧАНИЕ: Ваш метод также предполагает, что все работающие над Вашим приложением всегда не забывают санировать вход, прежде чем это поразит базу данных, которая, вероятно, не реалистична большую часть времени.
Это могло бы работать, но это кажется небольшой неаппетитной едой мне. Я рекомендовал бы verifing, что каждая строка допустима путем тестирования его против регулярного выражения вместо этого.
Patrick, Вы добавляете одинарные кавычки вокруг ВСЕГО входа, даже числового входа? Если Вы имеете числовой вход, но не помещаете одинарные кавычки вокруг этого, то у Вас есть воздействие.
Какова ужасный код вся эта санитизация ввода данных пользователем была бы! Затем неуклюжий StringBuilder для SQL-оператора. Подготовленными результатами метода оператора в намного более чистом коде и преимуществами Внедрения SQL является действительно хорошее дополнение.
Также, почему изобретают велосипед?
Если у Вас есть параметризированные запросы, доступные, необходимо использовать их в любом случае. Все это, который - взятия, чтобы один запрос проскользнул через сеть и Ваш DB, находится в опасности.
Да, это должно работать правильно вплоть до кого-то, кого выполнения УСТАНАВЛИВАЮТ QUOTED_IDENTIFIER ПРОЧЬ , и использует двойную кавычку на Вас.
Редактирование: Это не столь просто как не разрешение злонамеренному пользователю выключить идентификаторы в кавычках:
Собственный Клиент SQL Server драйвер ODBC и Собственный Клиентский Провайдер OLE DB SQL Server для SQL Server автоматически устанавливают QUOTED_IDENTIFIER на НА при соединении. Это может быть настроено в источниках данных ODBC в атрибутах соединения ODBC или свойствах подключения OLE DB. значение по умолчанию для НАБОРА QUOTED_IDENTIFIER ВЫКЛЮЧЕН для соединений из приложений Библиотеки DB.
, Когда хранимая процедура создается, , настройки SET QUOTED_IDENTIFIER и SET ANSI_NULLS получаются и используются для последующих вызовов того QUOTED_IDENTIFIER НАБОРА хранимой процедуры .
также , соответствует установке QUOTED_IDENTIFER ALTER DATABASE.
УСТАНАВЛИВАЕТ QUOTED_IDENTIFIER, набор во время синтаксического анализа . Установка во время синтаксического анализа означает что, если оператор SET присутствует в пакетной или хранимой процедуре, это вступает в силу, независимо от того, достигает ли выполнение кода на самом деле той точки; и оператор SET вступает в силу, прежде чем любые операторы выполняются.
существует много способов, которыми QUOTED_IDENTIFIER мог быть выключен без Вас обязательно знание его. По общему признанию - это не курящее использование оружия, которое Вы ищете, но это - довольно большая поверхность атаки. Конечно, если Вы также вышли из двойных кавычек - затем мы вернулись, где мы запустили. ;)
Ваша защита перестала бы работать если:
- запрос ожидает число, а не строку
- был любой другой способ представить единственную кавычку, включая:
- escape-последовательность такой как \039
- unicode символ
(в последнем случае, это должно было бы быть что-то, что было расширено только после выполнения замены)
Простой ответ: Это будет иногда работать, но не все время. Вы хотите использовать проверку белого списка на все , Вы делаете, но я понимаю, что это не всегда возможно, таким образом, Вы вынуждены пойти с лучшим черным списком предположения. Аналогично, Вы хотите использовать параметризованный, сохранил procs в все , но еще раз, это не всегда возможно, таким образом, Вы вынуждены использовать sp_execute с параметрами.
существуют пути вокруг любого применимого черного списка, который можно придумать (и некоторые белые списки также).
А достойная рецензия здесь: http://www.owasp.org/index.php/Top_10_2007-A2
, Если необходимо сделать это как быстрое исправление, чтобы дать Вам время для получения реального на месте, сделайте это. Но не думайте, что Вы в безопасности.
Это - плохая идея так или иначе, поскольку Вы, кажется, знаете.
Что относительно чего-то как выход из кавычки в строке как это: \'
Ваша замена привела бы к: \''
, Если обратная косая черта выходит из первой кавычки, то вторая кавычка закончила строку.
Входная санитария не что-то, что Вы хотите полузаднице. Используйте целую задницу. Используйте регулярные выражения на текстовых полях. TryCast Ваши численные данные к надлежащему числовому типу и отчет ошибка проверки, если это не работает. Очень легко искать шаблоны нападения в Вашем входе, такой как '-. Предположите, что весь вход от пользователя является враждебным.
Я использовал эту технику при контакте с функциональностью 'расширенного поиска', где создание запроса с нуля было единственным жизнеспособным ответом. (Пример: позвольте пользователю искать продукты на основе неограниченного набора ограничений на атрибуты продукта, отобразив столбцы и их разрешенные значения, поскольку GUI управляет для сокращения порога изучения для пользователей.)
Сам по себе это - безопасный AFAIK. Как другая отвечающая сторона, на которую указывают, однако, Вы, возможно, также должны иметь дело с выходом клавиши Backspace (хотя не при передаче запроса SQL Server с помощью ADO или ADO.NET, по крайней мере - не может ручаться за все базы данных или технологии).
препятствие - то, что действительно необходимо быть уверены, какие строки содержат ввод данных пользователем (всегда потенциально злонамеренный), и какие строки являются допустимыми SQL-запросами. Одно из прерываний - то, при использовании значений от базы данных - те значения были первоначально предоставлены пользователями? Если так, их нужно также оставить. Мой ответ должен попытаться санировать уже в возможном (но не позднее!), при построении SQL-запроса.
Однако в большинстве случаев, привязка параметров является способом пойти - это просто более просто.
Вкратце: Никогда не запрашивайте выход из себя. Вы обязаны получить что-то не так. Вместо этого используйте параметризированные запросы, или если Вы не можете сделать этого по некоторым причинам, пользоваться существующей библиотекой, которая делает это для Вас. Нет никакой причины сделать его самостоятельно.
Я понимаю, что это - долгое время после того, как вопрос задали, но..
Один способ начать атаку на 'кавычке аргумент' процедура со строковым усечением. Согласно MSDN, в SQL Server 2000 SP4 (и SQL Server 2005 SP1), слишком длинная строка будет бесшумно усеченной.
, Когда Вы заключаете в кавычки строку, строковые увеличения размера. Каждый апостроф повторяется. Это может затем использоваться для продвижения частей SQL вне буфера. Таким образом, Вы могли эффективно отрезать части где пункт.
Это, вероятно, было бы главным образом полезно в 'пользовательском администраторском сценарии страницы ', где Вы могли злоупотребить оператором 'обновления', чтобы не сделать все проверки, он, как предполагалось, сделал.
Поэтому, если Вы решаете заключить все аргументы в кавычки, удостоверьтесь, что Вы знаете то, что продолжает размеры строки, и проследите, чтобы Вы не сталкивались с усечением.
я рекомендовал бы идти с параметрами. Всегда. Просто желание я мог осуществить это в базе данных. И как побочный эффект, Вы, более вероятно, получите лучшие удачные обращения в кэш, потому что больше операторов выглядит одинаково. (Это было, конечно, верно на Oracle 8)
Существует два способа сделать это, никакие исключения, быть безопасным от Внедрений SQL; подготовленные операторы или prameterized хранимые процедуры.
Хорошо, этот ответ коснется обновления вопроса:
, "Если кто-либо знает о каком-либо особенном методе смонтировать атаку с использованием кода на SQL против этого метода санитизации, я хотел бы видеть его. "
Теперь, помимо выхода обратной косой черты MySQL - и принимая во внимание, что мы на самом деле говорим о MSSQL, существует на самом деле 3 возможных способа все еще SQL, вводящего Ваш код
sSanitizedInput =" '" & Замена (sInput, "'", "''") & "'"
Принимают во внимание, что они все не будут допустимы в любом случае и являются очень иждивенцем на Вашем фактическом коде вокруг этого:
- Внедрение SQL Второго порядка - если SQL-запрос восстановлен основанный на полученных данных от базы данных после выхода , данные связываются незавершенные и могут быть косвенно введены SQL. См.
- Строковое усечение - (немного более сложный) - Сценарий - Вы, имеют два поля, говорят имя пользователя и пароль, и SQL связывает их обоих. И оба поля (или просто первое) имеют жесткий предел длины. Например, имя пользователя ограничено 20 символами. Скажите, что у Вас есть этот код:
username = left(Replace(sInput, "'", "''"), 20)
Затем то, что Вы получаете - является именем пользователя, которого оставляют, и затем обрезало к 20 символам. Проблема здесь - я засуну свою кавычку в 20-й символ (например, после 19 a's), и Ваша кавычка выхода будет обрезана (в 21-м символе). Затем SQL
sSQL = "select * from USERS where username = '" + username + "' and password = '" + password + "'"
, объединенный с вышеупомянутым уродливым именем пользователя, приведет к паролю, уже являющемуся внешний кавычки, и будет просто содержать полезную нагрузку непосредственно.
3. Контрабанда Unicode - В определенных ситуациях, возможно передать высокий уровень unicode символ, который взгляды как кавычка, но не является - пока это не добирается до базы данных, где внезапно это . Так как это не кавычка при проверке его это пройдет легкий... Дополнительную информацию см. в моем предыдущем ответе и свяжитесь с исходным исследованием.