Невеб-внедрение SQL

Кто-то отправил бы доказательство контекста код Excel VBA для Внедрения SQL с помощью базы данных Jet в качестве бэкэнда? Или продемонстрируйте точно, какие параметры могли быть переданы коду в , Как возвратить значение в одном поле на основе справочного значения в другом поле , которое нанесет ущерб (вместо того, чтобы просто взломать код)?

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

, О, свободная подсказка (на предмет опасностей кроме традиционного Внедрения SQL):

1. сервис выражения Доступа недоступен через ODBC.

2. это доступно через DDE, но я не знаю, можно ли передать SQL Доступу через DDE (я не использовал DDE с Доступом приблизительно за 10 лет).

3. , если Вы ничего не знаете о Доступе и Струйных услугах по выражению, Вы, вероятно, не квалифицированы для ответа на вопрос о Струе (и Доступ).

Три точки:

1. Используя параметрические запросы обычно меньше работы, чем выход из возможных способов повредить Ваш SQL (г-н O'Neill, например) так, чтобы можно было связать данные в строку запроса непосредственно. Если более устойчивая опция является также меньшим количеством работы для реализации, то, почему был бы, Вы не хотите сделать это?

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

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

, Таким образом, абсолютно необходимо использовать параметризованные запросы, как показано в ответе Spolsky на другой вопрос, даже если не ради безопасности. Они не просто более безопасны, они являются также более стойкими к ошибке, часто более быстрыми для записи и являются с более высокими характеристиками для повторных запросов.

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

На самом деле, это не улучшит производительность в струе если Вы говорящий о производительности запросов. На самом деле, из СТРУЙНОГО отчета Обзор “Performance и Оптимизация Techniques”, мы получаем этот драгоценный камень:

страница 18

Начиная с сохраненных запросов имеет предварительно скомпилированный план запросов, параметризированные запросы, которые содержат параметры на индексированных столбцах, не могут выполниться эффективно. Так как механизм запроса не знает, что значения передаются в параметре заранее, он может только предположить относительно самого эффективного плана запросов. На основе клиентских сценариев производительности, которые мы исследовали, мы обнаружили, что в некоторых случаях существенное увеличение производительности может быть достигнуто путем замены сохраненного параметризированного запроса с временным запросом. Это означает создавать строку SQL в коде и передавать его ДАО OpenRecordset, или Выполните методы Объекта базы данных

, Аккуратного-o а? И, я испытал вышеупомянутое!

Имеют в виду, что время компиляции для плана запросов находится в 1000’s секунды так или иначе. Я имею в виду, действительно, время плана запросов проходит от.01 до.0001. Уверенный это в 100 раз быстрее, но это только сохраняет нас 100-я из секунды в целом. Мы выполняющий отчет, который занимает 2 секунды так, чтобы время плана запросов даже не было беспокойством.

у Нас есть РТЫ обработки сегодня. Это - дисководы, память и сеть i/o скорости, которые являются горлышками бутылки. У нас также don’t есть проблема траты кэша запроса SQL сервера для каждой новой строки sql, отправленной СТРУЕ. Те встроенные планы запросов SQL не кэшируются так или иначе. И, более важная СТРУЯ является основанным на клиенте механизмом поэтому, когда у Вас есть 10 пользователей на Вашей офисной LAN, у Вас есть 10 копий СТРУЙНОГО выполнения, локального на каждой машине. Кэш плана запросов не является проблемой как он, для SQL-сервера.

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

Однако для пребывания на ходу, должны согласиться с David. Я don’t думают это использующий odbc или в этом случае объектная модель дао + струя, я can’t при предложении ЛЮБОГО СПОСОБА ввести реальный sql оператор.

Каждый может, возможно, с “lame” InputBox (), пример выше вводит условия, которые могли бы привести к неожиданным результатам. Как указал, что приложения, созданные в доступе don’t, прокладывают себе путь очень часто.

Для вещей как удаление записи Вы просмотреть форму и это будет иметь панель пользовательского меню (или теперь лента), или просто удалить кнопка помещенный в форму. Пользователь таким образом can’t вводит неправильные данные для этого типа удаления кода.

более важный, когда мы действительно часто принимаем вход от пользователей на формах, имейте в виду, что наши формы имеют встроенные маски данных. В конце концов, это вполне очень, для чего был разработан доступ MS. Следовательно, если мы просим номер телефона, пользователь can’t вводят буквы или даже любого не числовые чартеры для той маски ввода. Та маска даже вставит () и †“в соответствующих местах в том номере телефона для дисплея, но только числа будут в в пользователях фактический вход.

Для большинства других типов подсказок мы используем поля комбинированного списка, lisboxes и другие элементы UI, который снова ограничивает пользовательскую способность ввести что-то другое затем, что та форма позволяет в то текстовое поле.

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

, Если кто-либо может показать СТРУЙНЫЙ пример, в котором пользователь может выполнить sql оператор инжекцией, я внимательно слушаю как я, don’t думают, что это возможно с дао + струя.

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

Dick, Это зависит, как Вы обрабатываете параметры. Вот пример VBA того, как не сделать вещи:

Friend Function DeleteAnAccount() As Boolean

  Const SQL_DELETE_AN_ACCOUNT As String * 50 = _
      "DELETE FROM Accounts WHERE account_owner_ID = '?';"

  Dim sql As String
  sql = Replace$(SQL_DELETE_AN_ACCOUNT, "?", txtAccountOwnerID.Text)

  m_Connection.Execute sql

End Function

Полагают это, если некоторый взмах, вместо того, чтобы ввести их идентификатор учетной записи в текстовое поле (txtAccountOwnerID), на самом деле ввел это:

dummy' OR 'a' = 'a

затем получающаяся строка SQL была бы этим:

DELETE FROM Accounts WHERE account_owner_ID = 'dummy' OR 'a' = 'a';

Не хороший becasue 'a' = 'a' предикат решил бы к TRUE, и все учетные записи будут удалены.

Лучше должен был бы использовать подготовленный оператор с помощью объекта ADODB.Command, например, Объектов параметра.

Jamie.

-

, Если я создаю макрос в Excel, который соединяется с базой данных Access, я должен действительно быть обеспокоен Внедрением SQL?

, Возможно. Это зависит, действительно. Я лично не был бы заинтересован, но какие данные Вы пытаетесь хранить и что, это - чувствительность?

, Если они достаточно умны, чтобы сделать Внедрение SQL, не они достаточно умный, чтобы взломать мой дополнительный пароль и просто изменить код?

, Возможно. Просто, потому что кто-то может сделать, внедрение SQL не означает, что они достаточно умны для взламывания дополнительного пароля. С другой стороны, они могли быть.

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

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

я написал код сам, который уязвим для Внедрения SQL, но единственные люди с таким доступом являются коллегами с доступом SQL так или иначе.

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

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

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

А хорошее эмпирическое правило состоит в том, чтобы спросить себя: Если я, с полным знанием этого продукта, требуемого для использования его для причинения вреда моей компании, сколько ущерба я мог нанести? Затем создайте в достаточной безопасности для перевода в нерабочее состояние того числа до терпимых уровней.

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

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

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

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

Я хотел бы подробно остановиться на комментарии, который я сделал выше в ответ на выделение сообщения onedaywhen, как использовать оператор SELECT в Доступе MS. Следует иметь в виду, что это не обобщенные комментарии о том, как защитить от Внедрения SQL, но подать заявку конкретно к программированию в Доступе MS.

я никогда не видел примера кода для Доступа, который позволил бы вид использования ВЫБОРА это обрисованный в общих чертах onedaywhen. Причина этого состоит в том, что почти никогда нет ситуации, где Вы использовали бы такие простые методы для сбора критериев без некоторой проверки входа где-нибудь по пути, чтобы не избежать Внедрения SQL, но избежать ошибок, вызванных недопустимым SQL.

Вот код, реализовывая самую простую версию этого:

Public Sub TestSQLExploit()
  Dim strSQL As String

  strSQL = "SELECT tblInventory.* FROM tblInventory WHERE InventoryID = "
  strSQL = strSQL & InputBox("Enter InventoryID")
  Debug.Print strSQL
End Sub

Так, передавая "10036 или =" производит этот SQL:

SELECT tblInventory.*
FROM tblInventory
WHERE InventoryID=10036 Or 'a'='a'

И это определенно не хорошо!

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

Public Sub TestSQLExploit1()
  Dim strSQL As String
  Dim strWhere As String

  strSQL = "SELECT tblInventory.* FROM tblInventory "
  strWhere = "WHERE " & Application.BuildCriteria("tblInventory.InventoryID", _
      dbLong, InputBox("Enter InventoryID"))
  strSQL = strSQL & strWhere
  Debug.Print strSQL
End Sub

я честно думал то Приложение. BuildCriteria бросил бы ошибку на это, но он не делает, и, когда передано "10036, или =" производит точно тот же SQL. И из-за пути работает Струйный сервис выражения, это было бы широко открытым, как Вы говорите.

Теперь, я никогда на самом деле пишу непрерывный SQL как это, потому что мне просто не нравится InputBox () функция, точно потому что необходимо записать набор кода для проверки входа. И если бы Вы использовали его как код выше, то необходимо было бы сделать много, чтобы удостовериться, что это было допустимо.

я никогда не видел примеров Кода доступа для этого вида операции, которая не рекомендует использовать, параметризовал SQL (который, конечно, избежит проблемы), или интерфейс Query-By-Form. Я обычно не использую сохраненные запросы параметров в Доступе, потому что мне нравится писать мои сохраненные запросы, чтобы быть применимым везде. Это означает, что у них главным образом нет операторов Where, которые имеют критерии то изменение во времени выполнения. Когда я использую эти сохраненные запросы, я обеспечиваю оператор Where для соответствующей ситуации, ли как recordsource в форме или rowsource для поля списка или выпадающего списка.

Теперь, точка здесь - то, что я не прошу у пользователя вход в этих случаях, но тяну значения критериев из объектов Доступа, таких как управление на форме. Теперь, в большинстве случаев, это было бы управлением на форме, которая имеет только одну цель - для сбора критериев некоторой формы фильтрации. Не было бы никаких непроверенных свободных текстовых полей на той форме - поля даты будут иметь маски ввода (который ограничил бы вход допустимыми датами), и поля, которые имеют ограниченное количество допустимых значений, имели бы типы управления, которые ограничивают выбор допустимыми данными. Обычно это было бы чем-то как выпадающее или группа опции.

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

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

, Если у меня есть текстовое поле, где пользователь входит "fent* или =", и я использую это в операторе Where:

WHERE tblDonor.LName Like "fent* or 'a' = 'a'"

результат состоит в том, что ничто не найдено. Если пользователь вошел "fent* или =", это все еще не будет работать, потому что это - текстовое поле, и я использую двойную кавычку вокруг этого. Если вводимый пользователь:

fent* or "a" = "a"

, который повредится также, потому что, когда мой код поместит двойные кавычки вокруг этого, оператор Where будет недопустим.

Теперь, со случаем просто взятия входа использования и помещения двойных кавычек вокруг этого, ясно что ввод этого:

" Or "fent*" or "a" = "a" Or "

привел бы к:

WHERE tblDonor.LName Like "" Or "fent*" or "a" = "a" Or ""

и это было бы очень плохо, так как это возвратит все. Но в моих существующих приложениях, я уже чищу двойные кавычки из ввода данных пользователем (так как двойные кавычки теоретически допустимы в поле LName), таким образом, мои приложения создают этот оператор Where:

WHERE tblDonor.LName Like "? Or ?fent*? or ?a? = ?a? Or ?*"

, Который не возвратит строк.

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

======

Некоторые заключения:

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

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

то, Что это означает на практической основе, - то, что, если Вы хотите собрать несколько критериев, необходимо сделать это способом, который пользователь может только выбрать из заданных величин. Самый простой способ сделать, который является с мультиизбранным полем списка (или пара их с ADD>> и < < УДАЛИТЕ промежуточные кнопки).

, Конечно, необходимо ли волноваться об этом виде ИЗБРАННОГО использования, зависит на уровне важности и конфиденциальности данных, получаемых, и точно что возвращается пользователю. Это не могла бы быть без проблем, чтобы рискнуть возвращать все строки нечувствительных данных при представлении данных в недоступной для редактирования форме (например, отчет), тогда как это могло бы быть проблематично, если бы Вы представили его в доступной для редактирования форме, и кто-то изменил данные, которые не должны быть отредактированы.

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

Так, моя еда на дом на всем этом:

1. никогда использование InputBox () для сбора критериев (этот я уже избегаю).

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

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

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

, Но это - хорошее напоминание мне, чтобы не быть удовлетворенным. Я думал то Приложение. BuildCriteria защитил бы меня, но теперь понял бы, что Струйный сервис выражения является слишком прощающим в том, что он принимает в операторе Where.

РЕДАКТИРОВАНИЕ 08.12.2009: Просто найденный этими ссылками на Внедрение SQL в Доступе MS. Все они предназначены для веб-инжекции, таким образом, не непосредственно применимый к обсуждению невеб-Внедрения SQL (многие из них были бы пустой тратой времени в интерактивном Доступе, поскольку у Вас уже будет доступ к большой информации, вынуждаемой скотами, например, информации о файловой системе, путях, исполняемых файлах, и т.д.), но многие методы также работали бы в приложении Доступа. Кроме того, выполнение от Доступа открывает много функций, которые не были бы выполнимы от ODBC/OLEDB. Пища для размышления.

• Доступ Через Доступ (PDF)
• Тестирование на Доступ MS
• Шпаргалка Внедрения SQL Доступа мс

Вы никогда не знаете, когда bobby таблицы собираются использовать Ваш макрос слова:

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

Вы уверенный , что ни одна из Ваших записей никогда не будет иметь apostophe (') в них?

INSERT INTO NAMES (FIRSTNAME, LASTNAME) VALUES('Jack', 'O'Neill')

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

Нет. (Да). Да. :)

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

Это все хорошо и хорошо сделать общий оператор о безопасности, но это должно соответствовать требованиям.