Это хороший подход для избежания SQL-инъекций?

Question

Здесь, в компании, в которой я работаю, у нас есть инструмент поддержки, который, помимо прочего, предоставляет страницу, позволяющую пользователю выполнять запросы SELECT.Это должно препятствовать выполнению пользователем UPDATE, INSERT, DELETE, DROP и т. Д. Кроме того, каждый оператор выбора принимается.

Способ, которым он работает, заключается в выполнении

SELECT * FROM (<query>)

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

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

Чтобы проверить его, я попытался написать что-то вроде

SELECT * from dual); DROP table users --

Но это не удалось из-за ; символ, который не принимается соединителем SQL.

Итак, есть ли способ добавить оператор модификации в запрос, подобный этому?

Кстати,это Oracle SQL.

РЕДАКТИРОВАТЬ:

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

Answer 1

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

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

Oracle - это многофункциональная БД, а это означает, что существует множество способов запуска DML из запроса.Вам нужно будет найти встроенную функцию PL / SQL, которая позволит вам выполнять DML или иметь другие побочные эффекты.Это будет зависеть от конкретной схемы в отношении того, какие пакеты доступны: у пакетов XML DB есть некоторые механизмы для запуска произвольного SQL, пакеты UTL_HTTP часто могут использоваться для запуска сетевых атак, а функциональность java довольно мощная.

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

Answer 2

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

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

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

И, возможно, также следует учитывать, что если «запрашивать все, что вам нравится» - это действительно необходимая функция, товаша СУБД, скорее всего, уже имеет некоторый инструмент или компонент, который фактически позволяет это ... (и даже разработан специально для этой цели).