Инъекция SQL без веба

Question

Кажется, есть некоторая истерия по поводу атак с использованием SQL-инъекций. Совсем недавно здесь

Как вернуть значение в одном поле на основе значения поиска в другом поле

Если я создаю макрос в Excel, который подключается к базе данных Access, действительно ли я должен беспокоиться о внедрении SQL? Это не в Интернете, оно используется в моем офисе (вы, ребята, помните десктопы, верно?). Я не обеспокоен тем, что мои коллеги собираются саботировать меня. Если они достаточно умны, чтобы делать инъекции SQL, разве они не достаточно умны, чтобы взломать мой пароль надстройки и просто изменить код?

Answer 1

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

На самом деле, это не улучшит производительность в струе, если вы говорите о производительности запросов. Фактически, из документа JET «Обзор производительности и методы оптимизации» мы получаем этот драгоценный камень:

стр. 18

Поскольку хранимые запросы имеют предварительно скомпилированный план запросов, параметризованные запросы, содержащие параметры в индексированных столбцах, могут выполняться неэффективно. Поскольку механизм запросов не знает значений, которые должны быть переданы в параметре заранее, он может только догадываться о наиболее эффективном плане запроса. Исходя из рассмотренных нами сценариев производительности клиентов, мы обнаружили, что в некоторых случаях можно добиться существенного повышения производительности путем замены хранимого параметризованного запроса временным запросом. Это означает создание строки SQL в коде и передачу ее методам DAO OpenRecordset или Execute объекта Database

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

Имейте в виду, что время компиляции для плана запроса в любом случае составляет тысячи секунд. Я имею в виду, на самом деле, время плана запроса изменяется от 0,01 до 0,0001. Конечно, это в 100 раз быстрее, но это всего лишь экономит нам одну сотую секунды. Мы запускаем отчет, который занимает 2 секунды, поэтому время планирования запроса даже не является проблемой.

Сегодня у нас есть ГОВ обработки. Это узкие места для дисков, памяти и скорости сетевого ввода / вывода. У нас также нет проблемы с использованием кэша SQL-запросов сервера для каждой новой строки SQL-запроса, отправляемой в JET. Эти встроенные планы SQL-запросов в любом случае не кэшируются. И, что еще важнее, JET - это клиентский движок, поэтому, когда у вас есть 10 пользователей в офисе, у вас есть 10 копий JET, работающих локально на каждом компьютере. Кеш плана запросов не является проблемой, как для сервера SQL.

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

Однако, чтобы не сбиться с пути, нужно согласиться с Дэвидом. Я не думаю, что когда вы используете odbc или, в данном случае, объектную модель dao + jet, я не могу придумать ЛЮБОГО СПОСОБА ввести реальный SQL-оператор.

Возможно, с приведенным выше примером «lame» InputBox () можно ввести условия, которые могут привести к неожиданным результатам. Как уже указывалось, встроенные приложения доступа не очень часто работают таким образом.

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

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

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

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

Если кто-то может показать пример JET, в котором пользователь может выполнить SQL-оператор путем инъекции, я весь в ушах, так как не думаю, что это возможно с dao + jet.

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

Answer 2

Три очка:

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

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

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

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

Answer 3

Дик, это зависит как вы обрабатываете параметры. Вот пример 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';

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

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

Джейми.

-

Answer 4

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

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

Да, бесплатная подсказка (на тему опасностей, отличных от традиционных SQL-инъекций):

1. Служба выражений доступа недоступна через ODBC.

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

3. Если вы ничего не знаете о службах Access и Jet Express, вы, вероятно, не имеете права отвечать на вопрос о Jet (и Access).

Answer 5

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

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

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

Может быть. То, что кто-то может сделать инъекцию SQL, не означает, что он достаточно умен взломать ваш пароль надстройки. С другой стороны, они могут быть.