Как предотвратить инъекцию SQL в Oracle SQLPlus?

Question

Очевидно, что если я использую JDBC / ODBC, я могу использовать переменные связывания и подготовленные операторы для предотвращения внедрения SQL. Однако когда данные передаются пакетным процессам, которые в конечном итоге вызывают Oracle SQLPlus, есть ли способ предотвратить внедрение SQL? Например:

query.sql:

select '&1' from dual;
exit;

Если я вызываю этот скрипт из SQLPlus таким образом:

$ sqlplus SCOTT/TIGER @query.sql "x','y"

Я получу следующий вывод:

old   1: select '&1' from dual
new   1: select 'x','y' from dual

' '
- -
x y

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

Answer 1

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

Answer 2

Передача параметров через SQL * Plus через командную строку будет открыта не только для внедрения SQL, так как командная строка будет сначала интерпретироваться через ОС. Поэтому вам также необходимо подумать о том, что может сделать пользователь ОС.

Лично я бы отказался от SQL * Plus и пошел бы с чем-то вроде Perl. У вас есть подходящий язык программирования для переноса ваших операторов SQL с гораздо лучшей обработкой переменных и исключений.

Answer 3

Вы можете использовать следующую команду SQL Plus:

SET DEFINE OFF

Answer 4

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

variable my_var varchar2(100);
begin
:my_var := &1;
end;
/
select :my_var from dual;

Переменная my_var будет связана с запросом. Вместо простого поиска / замены.

Answer 5

На самом деле вы не можете подвергаться атакам с использованием SQL-инъекций, если не хотите выставлять свои скрипты SQL * Plus злоумышленникам в Интернете. Люди, которые действительно будут атаковать вашу компанию.

Похоже, вы говорите о пакетных заданиях, выполняемых собственными силами; полностью за брандмауэром, где остальные пользователи сети являются вашими коллегами, верно?

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

---

Редактировать

Хотя я не могу притворяться, что знаю, что означает «поломка из-за управляющих символов», я могу дать некоторые дополнительные советы.

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

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