Михаил Разумов, по материалам SecurityFocus Это вторая часть из серии статей, исследующих атаки SQL инъекции против баз данных Oracle. Первая статья содержала обзор SQL инъекции и того, как приложения базы данных Oracle уязвимы к этой атаке, также были рассмотрены несколько примеров. Эта часть сосредоточится на определении привилегий, обнаружении атак SQL инъекции, и защите против SQL инъекции. Определение Привилегий Возможность осуществлять SQL инъекции в базу данных Oracle – это само по себе уже много, но на что обратит внимание атакующий для увеличения своих возможностей? Конечно, ему может понадобиться определить, что может видеть и делать пользователь, к которому он получил доступ. Я покажу здесь несколько примеров, чтобы читатели поняли, что можно сделать. В этом примере, мы вошли как пользователь dbsnmp и изменили процедуру get_cust таким образом, чтобы выбрать три колонки из выбранной нами таблицы. Если мы используем union, чтобы расширить существующий запрос select, тогда новый SQL в union должен выбирать то же количество колонок и те же типы данных, как и существующий select, иначе возникнет ошибка, как показано ниже: SQL> exec get_cust('x'' union select 1,''Y'' from sys.dual where ''x''=''x'); debug:select customer_phone,customer_forname,customer_surname from customers where customer_surname='x' union select 1,'Y' from sys.dual where 'x'='x' -1789ORA-01789: query block has incorrect number of result columns Основной select здесь имеет три колонки varchar, а мы выбираем две колонки, одна из которых является числовой; в результате возникает ошибка. Возвращаясь к определению привилегий, сначала определим объекты, которые может видеть пользователь, под которым мы вошли: SQL> exec get_cust('x'' union select object_name,object_type,''x'' from user_obj ects where ''x''=''x'); debug:select customer_phone,customer_forname,customer_surname from customers where customer_surname='x' union select object_name,object_type,'x' from user_objects where 'x'='x' ::CUSTOMERS:TABLE:x :BA_DATA_FILES:SYNONYM:x :BA_FREE_SPACE:SYNONYM:x :BA_SEGMENTS:SYNONYM:x :BA_TABLESPACES:SYNONYM:x ::GET_CUSTROCEDURE:x ::GET_CUST2ROCEDURE:x ::GET_CUST_BINDROCEDURE:x :LSQATABASE LINK:x Затем определим роли, которые определены для пользователя: SQL> exec get_cust('x'' union select granted_role,admin_option,default_role from user_role_privs where ''x''=''x'); debug:select customer_phone,customer_forname,customer_surname from customers where customer_surname='x' union select granted_role,admin_option,default_role from user_role_privs where 'x'='x' ::CONNECT:NO:YES ::RESOURCE:NO:YES ::SNMPAGENT:NO:YES После этого определим системные привилегии, назначенные пользователю: SQL> exec get_cust('x'' union select privilege,admin_option,''X'' from user_sys_ privs where ''x''=''x'); debug:select customer_phone,customer_forname,customer_surname from customers where customer_surname='x' union select privilege,admin_option,'X' from user_sys_privs where 'x'='x' ::CREATE PUBLIC SYNONYM:NO:X ::UNLIMITED TABLESPACE:NO:X Выбор из таблицы USER_TAB_PRIVS даст нам привилегии, данные пользователю по отношению к объектам. Существует много системных представлений (views), которые начинаются с USER_%, они показывают объекты и привилегии, которые назначены текущему пользователю, а также подробности об объектах, которые принадлежат пользователю. Например, есть 168 представлений или таблиц в Oracle 8.1.7; это показывает множество деталей, которые можно узнать о пользователе, под которым вы вошли. Представления USER_% не включают все возможные привилегии и возможности, доступные текущему пользователю; однако, помимо тех, что предоставлены отдельно, любой пользователь также может иметь доступ ко всем объектам, к которым дан доступ для PUBLIC. PUBLIC – это объединение, которое доступно всем пользователям базы данных Oracle. Существует хороший набор представлений, известных как ALL_%, которые по структуре аналогичны представлениям USER_%. ALL_% включают в себя все, что доступно текущему пользователю, включая PUBLIC. Хорошая точка для старта – представление ALL_OBJECTS, так как оно имеет такую же структуру, как и USER_OBJECTS и показывает все объекты и их типы, доступные текущему пользователю. Хороший запрос, позволяющий увидеть все объекты, их типы и владельца, выглядит так: select count(*),object_type,owner from all_objects group by object_type,owner Представления V$ также представляют собой хороший набор, если они доступны для пользователя. Они дают информацию о текущих экземплярах (instance), производительности (performance), параметрах, и т.п. Хорошим примером является V$PARAMETER, который дает все параметры инициализации экземпляра базы данных (database instance), включая детали директорий UTL_FILE. V$PROCESS и V$SESSION – другая пара представлений, которые дают детали о текущих сессиях и процессах. Они скажут пользователю, кто в настоящий момент подключен к базе, откуда они подключены, какую программу они используют и т.д. В заключение к этой исследовательской главе стоит упомянуть, что поскольку я хотел создать легкие примеры, которые сможет повторить кто угодно, имея копию Oracle RDBMS (Relational DataBase Management System - система управления реляционной базой данных), я использовал процедуру PL/SQL, чтобы продемонстрировать методы, и очевидно, я имел доступ к своему исходному коду. Это облегчило мне задачу написания SQL запросов, которые я смог бы успешно отправлять, не получая ошибок. В реальном мире, в веб-среде, или сетевом приложении, исходный код вряд ли будет доступен. В результате, получение удачного SQL запроса возможно методом проб и ошибок. Если пользователю возвращается сообщение об ошибке, либо непосредственно с Oracle RDBMS, либо из приложения, обычно есть возможность понять, где требуется изменение в SQL. Отсутствие сообщений об ошибке делает это более сложным, но не невозможным. Все сообщения об ошибках Oracle хорошо документированы и доступны online на Unix-системе командой oerr, или в виде документации в формате HTML, предоставляемой на CD с Oracle для любой платформы. (Помните, что можно свободно копировать Oracle с целью изучения.) Дистрибутив Oracle и документация доступны в online режиме с http://tahiti.oracle.com/. Знание Oracle и используемой схемы пользователя также дает большое преимущество. Вполне очевидно, что некоторые их этих знаний несложно получить, так что помните о том, что в случае, если кто угодно может осуществить SQL инъекцию в вашу базу данных, вам следует минимизировать то, что они смогут сделать, увидеть, или к чему получить доступ. Обнаружение SQL инъекции Oracle – большой продукт, применяемый для многих целей, так что утверждение, что SQL инъекцию можно обнаружить, является ложным; однако, в некоторых случаях, для DBA или security admin может оказаться возможным определить, использовалась ли эта техника. Если подозревается, что имело место нападение, можно провести компьютерную экспертизу с использованием redo логов. От Oracle доступна GUI утилита под названием Log Miner для анализа redo логов. Однако, существуют серьезные ограничения: до версии 9i, оператор select не может быть восстановлен. Redo логи позволяют Oracle переиграть все события, которые привели к изменению данных в базе, это часть возможностей восстановления. Можно увидеть все запросы и данные, которые были изменены. Существуют два стандартных пакета PL/SQL, DBMS_LOGMNR и DBMS_LOGMNR_D, эти пакеты позволяют запрашивать из командной строки redo логи для всех обработанных запросов. Широкие функциональные возможности аудита Oracle можно использовать, но, если вы не знаете, чего ищите, поиск свидетельств SQL инъекции может оказаться подобием поиска иголки в стоге сена. В любой базе данных Oracle необходимо соблюдать принцип наименьших привилегий, таким образом, чтобы пользователям базы предоставлялись только те права, которые фактически необходимы. Это сокращает количество авторизованных действий, в результате, делает более легким определение любых действий, лежащих вне возможностей этих пользователей. Например, если пользователь приложения Oracle должен иметь доступ к семи таблицам и трем процедурам, и ничему более, то использование аудита ошибок Oracle для записи ошибок оператора select по отношению ко всем другим таблицам должно позволить администратору обнаружить любые попытки доступа за пределы, относящиеся к этому приложению. Это можно сделать, к примеру, для одной таблицы следующей командой аудита: SQL> audit select on dbsnmp.customers by access whenever not successful; Audit succeeded. Можно написать простой скрипт для включения аудита ошибок для требуемых таблиц. Не должно возникнуть заметных проблем с производительностью из-за аудита, так как к этим таблицам приложение не должно обращаться, а следовательно, не должно создавать ошибок. Конечно, если кто-то успешно обратится к таблице за пределами, определенными для приложения, это не будет обнаружено. Эта мера является просто первым шагом. Те же принципы аудита могут быть использованы для DDL, ошибок или успехов вставки или обновления. Другая идея состоит в наблюдении за запускаемыми запросами SQL и поиске подозрительных запросов. Можно использовать хороший скрипт peep.sq для доступа к SQL, запускаемым из SGA (System Global Area – Глобальная Область Системы). Этот скрипт показывает SQL запросы в SGA с худшими временными характеристиками выполнения. Он может быть легко изменен удалением ограничений на время исполнения, показывая таким образом все SQL в SGA. Такой скрипт можно запускать по графику, и затем возвращаемый SQL можно использовать для предположения, предпринимались ли какие-то попытки SQL инъекции. Я говорю «предположения», потому что практически невозможно знать все корректные части SQL, которые создает приложение; следовательно, то же самое относится к обнаружению некорректных. Хорошим началом было бы обнаружение всех запросов, содержащих “union”, или or со строками типа ‘x’=’x’. Возможны проблемы с производительностью при регулярном выделении всех SQL из SGA. Лучшее лечение – это, безусловно, предупреждение! Защита от SQL инъекции Кажется, что защиту от SQL инъекции легко реализовать, однако в действительности, это не так просто, как кажется. Решения разделяются на две области: Не разрешайте динамических SQL, которые используют конкатенацию, или, по крайней мере, фильтруйте входные значения и проверяйте на специальные символы типа кавычек. Используйте принцип наименьших привилегий и убедитесь, что пользователи, созданные для приложений, имеют те права доступа, которые им нужны, а все дополнительные (такие, как PUBLIC) отключены. Мы не будем вдаваться в подробности в этой главе; для этого нужно писать отдельную статью. Однако, необходимо предпринять некоторые основные меры: Проверьте исходный код приложений. Код может быть написан на множестве различных языков, таких как PHP, JSP, java, PL/SQL VB, и т.д., так что решения могут быть различны. Однако, все они похожи. Просмотрите исходный код на наличие динамического SQL с использованием конкатенации. Найдите вызов, который анализирует SQL и запускает на выполнение. Найдите, где вводятся значения. Убедитесь, что входные значения проверяются на корректность, что кавычки совпадают и проверяются метасимволы. Анализ исходного кода – это задача, зависящая от используемого языка. Защитите базу данных и убедитесь, что все избыточные полномочия запрещены. Некоторые другие простые советы: Если это возможно, не используйте динамические PL/SQL. Потенциальный ущерб в этом случае намного выше, чем в случае динамического SQL, так как появляется возможность исполнять любой SQL, DDL, PL/SQL и т.д. Если динамический PL/SQL необходим, используйте переменные bind. Если используется PL/SQL, используйте AUTHID CURRENT_USER, чтобы PL/SQL запускался от имени вошедшего пользователя, а не создателя процедуры, функции, или программы. Если требуется конкатенация, используйте числовые значения. Таким образом, нельзя будет передать строки для добавления SQL. Если требуется конкатенация, проверяйте входные параметры на злонамеренный код, например, проверяйте наличие union в переданной строке, или метасимволов, таких как кавычки. Для динамического SQL необходимо использовать bind переменные. Ниже показан пример: create or replace procedure get_cust_bind (lv_surname in varchar2) is type cv_typ is ref cursor; cv cv_typ; lv_phone customers.customer_phone%type; lv_stmt varchar2(32767):='select customer_phone '|| 'from customers '|| 'where customer_surname=:surname'; begin dbms_output.put_line('debug:'||lv_stmt); open cv for lv_stmt using lv_surname; loop fetch cv into lv_phone; exit when cv%notfound; dbms_output.put_line('::'||lv_phone); end loop; close cv; exception when others then dbms_output.put_line(sqlcode||sqlerrm); end get_cust_bind; / Сначала мы запустим функцию с нормальным значением параметра, в данном случае “Clark”, чтобы увидеть, что возвращаются корректные записи. Затем, когда мы попытаемся сделать SQL инъекцию в эту процедуру, мы увидим, что это не сработает: SQL> exec get_cust_bind('Clark'); debug:select customer_phone from customers where customer_surname=:surname ::999444888 ::999777888 PL/SQL procedure successfully completed. SQL> exec get_cust_bind('x'' union select username from all_users where ''x''='' x'); debug:select customer_phone from customers where customer_surname=:surname Еще некоторые советы: Шифруйте чувствительные данные, чтобы их нельзя было посмотреть. Запретите все PUBLIC привилегии в базе данных, где это возможно. Не разрешайте доступ к UTL_FILE, DBMS_LOB, DBMS_PIPE, DBMS_OUTPUT, UTL_HTTP,UTL_SMTP или любым другим стандартным приложениям, дающим доступ к ОС. Смените заданные по умолчанию пароли в базе данных. Запускайте listener от имени непривилегированного пользователя. Убедитесь, что для пользователей приложений определен минимум прав. Ограничьте PL/SQL пакеты, к которым есть доступ из apache. Удалите все примеры скриптов и программ из установки Oracle. Заключение Надеюсь, что эта статья предоставила обзор некоторых возможностей SQL инъекции в Oracle с примерами, которые смогут повторить большинство читателей. Напомню, SQL инъекция – относительно простая техника, и кажется, что защита от нее должна быть элементарной; однако аудит всего исходного кода и защита динамического ввода – нетривиальная задача, как и ограничение прав всех пользователей приложений в самой базе данных. Будьте бдительны, предоставляйте только то, что нужно, и попытайтесь уменьшить количество динамического SQL до минимума.
