Я могу защитить от Внедрения SQL путем выхода из одинарной кавычки и окружающего ввода данных пользователем с одинарными кавычками?

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

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

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

Мы используем Microsoft SQL Server 2000, для которого я полагаю, что одинарная кавычка является единственным строковым разделителем и единственным способом выйти из строкового разделителя, таким образом, нет никакого способа выполнить что-либо, что пользователь вводит.

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

Что случилось с этим кодом? Существует ли способ получить атаку с использованием кода на SQL мимо этого метода санитизации? Демонстрационный ввод данных пользователем, который использует эту технику, был бы очень полезен.


ОБНОВЛЕНИЕ:

Я все еще не знаю ни о каком способе эффективно запустить атаку с использованием кода на SQL против этого кода. Несколько человек предположили, что обратная косая черта выйдет из одной одинарной кавычки и оставит другой для окончания строки так, чтобы остальная часть строки была бы выполнена как часть команды SQL, и я понимаю, что этот метод работал бы для введения SQL в базу данных MySQL, но в SQL Server 2000 единственный путь (что я смог найти) для выхода из одинарной кавычки с другой одинарной кавычкой; обратные косые черты не сделают этого.

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

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

131
задан Peter Mortensen 15 July 2019 в 23:04
поделиться

17 ответов

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

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

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

надлежащий способ сделать это:

  • проверка Белого списка: тип, длина, формат или принятые значения
  • , Если Вы хотите поместить в черный список, идет прямо вперед. Выход кавычки хорош, но в контексте другого смягчения.
  • Объекты команды Использования и Объекты параметра, чтобы предварительно проанализировать и проверить
  • параметризированные запросы Вызова только.
  • Еще лучше, используйте Хранимые процедуры исключительно.
  • Избегают использования динамического SQL и не используют конкатенацию строк для создания запросов.
  • При использовании SPS, можно также ограничить полномочия в базе данных к выполнению необходимого SPS только и не таблиц доступа непосредственно.
  • можно также легко проверить, что вся кодовая база только получает доступ к DB через SPS
86
ответ дан 24 November 2019 в 00:17
поделиться

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

Это - большая дополнительная работа.

-1
ответ дан 24 November 2019 в 00:17
поделиться

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

Так или иначе, это - что-то вроде клуджа... особенно, когда у Вас законно есть вещи (как имена), который может использовать одинарные кавычки...

ПРИМЕЧАНИЕ: Ваш метод также предполагает, что все работающие над Вашим приложением всегда не забывают санировать вход, прежде чем это поразит базу данных, которая, вероятно, не реалистична большую часть времени.

1
ответ дан 24 November 2019 в 00:17
поделиться

Это могло бы работать, но это кажется небольшой неаппетитной едой мне. Я рекомендовал бы verifing, что каждая строка допустима путем тестирования его против регулярного выражения вместо этого.

-2
ответ дан 24 November 2019 в 00:17
поделиться

Patrick, Вы добавляете одинарные кавычки вокруг ВСЕГО входа, даже числового входа? Если Вы имеете числовой вход, но не помещаете одинарные кавычки вокруг этого, то у Вас есть воздействие.

4
ответ дан 24 November 2019 в 00:17
поделиться

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

Также, почему изобретают велосипед?

1
ответ дан 24 November 2019 в 00:17
поделиться

Если у Вас есть параметризированные запросы, доступные, необходимо использовать их в любом случае. Все это, который - взятия, чтобы один запрос проскользнул через сеть и Ваш DB, находится в опасности.

4
ответ дан 24 November 2019 в 00:17
поделиться

Да, это должно работать правильно вплоть до кого-то, кого выполнения УСТАНАВЛИВАЮТ 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 мог быть выключен без Вас обязательно знание его. По общему признанию - это не курящее использование оружия, которое Вы ищете, но это - довольно большая поверхность атаки. Конечно, если Вы также вышли из двойных кавычек - затем мы вернулись, где мы запустили. ;)

4
ответ дан 24 November 2019 в 00:17
поделиться

Ваша защита перестала бы работать если:

  • запрос ожидает число, а не строку
  • был любой другой способ представить единственную кавычку, включая:
    • escape-последовательность такой как \039
    • unicode символ

(в последнем случае, это должно было бы быть что-то, что было расширено только после выполнения замены)

4
ответ дан 24 November 2019 в 00:17
поделиться

Простой ответ: Это будет иногда работать, но не все время. Вы хотите использовать проверку белого списка на все , Вы делаете, но я понимаю, что это не всегда возможно, таким образом, Вы вынуждены пойти с лучшим черным списком предположения. Аналогично, Вы хотите использовать параметризованный, сохранил procs в все , но еще раз, это не всегда возможно, таким образом, Вы вынуждены использовать sp_execute с параметрами.

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

А достойная рецензия здесь: http://www.owasp.org/index.php/Top_10_2007-A2

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

6
ответ дан 24 November 2019 в 00:17
поделиться

Это - плохая идея так или иначе, поскольку Вы, кажется, знаете.

Что относительно чего-то как выход из кавычки в строке как это: \'

Ваша замена привела бы к: \''

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

6
ответ дан 24 November 2019 в 00:17
поделиться

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

8
ответ дан 24 November 2019 в 00:17
поделиться

Я использовал эту технику при контакте с функциональностью 'расширенного поиска', где создание запроса с нуля было единственным жизнеспособным ответом. (Пример: позвольте пользователю искать продукты на основе неограниченного набора ограничений на атрибуты продукта, отобразив столбцы и их разрешенные значения, поскольку GUI управляет для сокращения порога изучения для пользователей.)

Сам по себе это - безопасный AFAIK. Как другая отвечающая сторона, на которую указывают, однако, Вы, возможно, также должны иметь дело с выходом клавиши Backspace (хотя не при передаче запроса SQL Server с помощью ADO или ADO.NET, по крайней мере - не может ручаться за все базы данных или технологии).

препятствие - то, что действительно необходимо быть уверены, какие строки содержат ввод данных пользователем (всегда потенциально злонамеренный), и какие строки являются допустимыми SQL-запросами. Одно из прерываний - то, при использовании значений от базы данных - те значения были первоначально предоставлены пользователями? Если так, их нужно также оставить. Мой ответ должен попытаться санировать уже в возможном (но не позднее!), при построении SQL-запроса.

Однако в большинстве случаев, привязка параметров является способом пойти - это просто более просто.

9
ответ дан 24 November 2019 в 00:17
поделиться

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

28
ответ дан 24 November 2019 в 00:17
поделиться

Я понимаю, что это - долгое время после того, как вопрос задали, но..

Один способ начать атаку на 'кавычке аргумент' процедура со строковым усечением. Согласно MSDN, в SQL Server 2000 SP4 (и SQL Server 2005 SP1), слишком длинная строка будет бесшумно усеченной.

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

Это, вероятно, было бы главным образом полезно в 'пользовательском администраторском сценарии страницы ', где Вы могли злоупотребить оператором 'обновления', чтобы не сделать все проверки, он, как предполагалось, сделал.

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

я рекомендовал бы идти с параметрами. Всегда. Просто желание я мог осуществить это в базе данных. И как побочный эффект, Вы, более вероятно, получите лучшие удачные обращения в кэш, потому что больше операторов выглядит одинаково. (Это было, конечно, верно на Oracle 8)

18
ответ дан 24 November 2019 в 00:17
поделиться

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

6
ответ дан 24 November 2019 в 00:17
поделиться

Хорошо, этот ответ коснется обновления вопроса:

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

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

sSanitizedInput =" '" & Замена (sInput, "'", "''") & "'"

Принимают во внимание, что они все не будут допустимы в любом случае и являются очень иждивенцем на Вашем фактическом коде вокруг этого:

  1. Внедрение SQL Второго порядка - если SQL-запрос восстановлен основанный на полученных данных от базы данных после выхода , данные связываются незавершенные и могут быть косвенно введены SQL. См.
  2. Строковое усечение - (немного более сложный) - Сценарий - Вы, имеют два поля, говорят имя пользователя и пароль, и 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 символ, который взгляды как кавычка, но не является - пока это не добирается до базы данных, где внезапно это . Так как это не кавычка при проверке его это пройдет легкий... Дополнительную информацию см. в моем предыдущем ответе и свяжитесь с исходным исследованием.

40
ответ дан 24 November 2019 в 00:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: