sqlsqloraclebatch-filesql-injectionsqlplus

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

просмотры: 3.2K

Очевидно, что если я использую 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 используют простую подстановку макросов. Есть ли альтернативный метод, который мне не хватает? В противном случае, как мне предотвратить его использование?

Источник

Ответов (5)

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

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

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

Источник

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

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

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

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

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

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

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

Источник

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

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

Источник

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

Источник

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

SET DEFINE OFF
Источник