Неинвазивная реализация мандатного управления доступом в веб-приложениях на уровне СУБД | ПДМ. Приложение. 2015. № 8.

Неинвазивная реализация мандатного управления доступом в веб-приложениях на уровне СУБД

Предлагается неинвазивный метод (метод, не изменяющий исходный код самого приложения) устранения уязвимостей в механизмах логического управления доступом и информационными потоками в веб-приложениях на уровне СУБД. Задача ставится следующим образом: имеется многоуровневое веб-приложение, в котором реализована подсистема базового управление доступом (как правило, ролевого), возможно, имеющая некоторое множество уязвимостей. Необходимо устранить как можно более широкий класс данных уязвимостей без изменения исходного кода самого приложения или обеспечить реализацию новой политики мандатного управления доступом. Метод включает выполнение следующих шагов: идентификация субъектов веб-приложения с помощью специального интегрируемого модуля и передачи полученных идентификаторов в SQL-запросах; обработка SQL-запросов с учётом формальной политики мандатного управления доступом на уровне прокси-сервера; переписывание SQL-запросов для предотвращения несанкционированного доступа к данным.

Non-invasive method of mandatory access control implementaion on dbms layer in web applications.pdf Управление доступом в системах управления базами данных (СУБД) в большинстве случаев реализуется на уровне ядра системы. Однако такой подход имеет ряд недостатков. Во-первых, в подавляющем большинстве случаев реализуется управление доступом на основе дискреционной политики. Исключением являются специализированные защищённые СУБД, такие, как RUBIX [1], Линтер [2] или расширения для СУБД общего назначения, например пакет Oracle Label Security для СУБД Oracle [3], где реализуется политика мандатного управления доступом типа MLS. Во-вторых, в реализованных механизмах управления доступом, как и в любом другом программном обеспечении, могут содержаться ошибки. К примеру, сравнительно недавно в популярной СУБД MySQL была найдена уязвимость, позволяющая обойти процедуру аутентификации [4]. При этом ошибки могут быть не только в реализации системы, но и в её модели безопасности [5], особенно если речь идёт о достаточо сложном мандатном или ролевом управлении доступом. В то же время с точки зрения управления доступом СУБД, как правило, является отдельной информационной системой и функционирует независимо от приложения пользователя, которое её использует. В качестве примера можно рассмотреть типовое веб-приложение, которое содержит множество пользователей на уровне веб-сервера, но все они выполняют операции в СУБД от имени одной её учётной записи, соответствующей этому веб-приложению. Так как все операции на уровне СУБД выполняются от имени одной учётной записи, можно считать, что управление доступом на уровне СУБД отсутствует и в случае наличия ошибок в реализации управления доступом в коде веб-приложения злоумышленник может получить доступ к данным любого пользователя приложения, хранящимся в СУБД. В работе предлагается неинвазивный метод реализации управления доступом в веб-приложении на уровне СУБД MySQL, основанный на формальных моделях безопасности для СУБД MySQL [6, 7] и реализации монитора безопасности на уровне прокси-сервера для SQL-запросов [8]. Метод позволяет получить информацию об идентификаторах пользователей веб-приложения и передать их (прозрачно для веб-приложения) в SQL-запросах, а затем на уровне SQL-прокси реализовать заданную политику управления доступом. Процедура идентификации субъектов осуществляется с помощью технологии тэгирования - добавления к SQL-запросу идентификатора пользователя в форме комментария. После того как мы идентифицировали субъектов веб-приложения, необходимо идентифицировать сущности СУБД. В СУБД MySQL минимальной единицей доступа являются столбцы, поэтому стандартными средствами возможно реализовать управление доступом лишь до уровня столбцов, что недостаточно для современных защищённых веб-приложений. Для обеспечения возможности идентификации строк таблиц СУБД предложен метод определения принадлежности записи из защищаемой таблицы СУБД пользователю веб-приложения. Рассмотрим последний метод более детально. В некоторых СУБД, в том числе в СУБД MySQL и в порождённых от нее, например, в СУБД MariaDB, управление доступом не позволяет задать право доступа к строке таблицы. Наименьшим контейнером, к которому право доступа может быть задано, выступает столбец. Типовые веб-приложение часто используют таблицу для хранения однотипных записей всех пользователей. В этом случае отсутствие проверок допустимых значений входных данных пользователяей веб-приложения, влияющих на генерируемый SQL-запрос, может привести к несанкционированному доступу к данным. Предлагаемый метод включает анализ генерируемого SQL-запроса и добавление в него дополнительных условий. Анализ запроса состоит в проверке наличия защищаемой таблицы в списке таблиц, к которым осуществляется доступ. Защищаемой таблицей называется таблица, для столбца которой активирован описываемый механизм. Если такая таблица присутствует в запросе, то он модифицируется путём добавления условия в раздел WHERE или HAVING исходного SQL-запроса. Добавляемое условие формируется в момент анализа запроса из шаблона, описанного администратором в конфигурационном файле. Шаблон представляет собой кортеж из трёх объектов: - полного пути до защищаемого столбца в формате «БАЗА_ДАННЫХ.ТАБЛИЦА. СТОЛБЕЦ»; - регулярного выражения, поддерживаемого СУБД MySQL и соответствующего уникальному значению идентификатора пользователя; - пути, связывающего столбец с идентификаторами пользователей и столбец из защищаемой таблицы, если такой может быть построен. Второй и третий объекты решают задачу определения принадлежности записи конкретному пользователю. При этом возможны следующие варианты. Если защищаемая таблица содержит столбец с идентификаторами пользователей, то третий объект не обязателен для заполнения и может быть построено регулярное выражение с использованием предопределённых параметров, таких, как идентификатор пользователя, определяющий принадлежность записи. Если же защищаемая таблица содержит столбец, по которому возможно определить принадлежность записи пользователю через связи с другими таблицами, то третий объект может быть использован для описания этих связей. Например, если в защищаемой таблице хранятся зарплатные ведомости и первичным ключом является инкрементируемое числовое значение, то для связи владельца заработной платы и её значения может быть построен путь от первичного ключа защищаемой таблицы через промежуточную таблицу, реализующую связь многие ко многим, до столбца с идентификаторами пользователей. Основой прототипа является MySQL-proxy, реализующий политику мандатного управления доступом типа MLS и TE на основе разработанной ранее формальной ДП-модели [7]. Механизмы, позволяющие определить принадлежность записи из защищаемой таблицы СУБД пользователю веб-приложения, и идентификация пользователей веб-приложения реализованы в виде модулей веб-фреймворка Django. Общая схема полученного прототипа изображена на рис. 1. Рассмотрим процесс прохождения запроса пользователя веб-приложения к СУБД. Аутентифицированный пользователь веб-приложения отправляет HTTP-запрос на выполнение какого-либо действия. Это приводит к генерации SQL-запроса к СУБД MySQL. Перед отправкой запрос тэгируется идентификатором пользователя, инициировавшим его выполнение, с использованием модуля Django фреймворка. Основная функция модуля состоит в модификации некоторых методов класса-обёртки Cursor-Wrapper, который используется для перехвата некоторых исключений класса Cursor. В результате модификации SQL-запросы пользователя, генерируемые слоем Object-Relational Mapping фреймворка Django или написанные пользователем вручную, будут перехвачены и обработаны. Далее запрос, содержащий идентификатор пользователя, поступает на MySQL-proxy. Если механизм контроля записей сконфигурирован, то осуществляется анализ SQL-запроса. В результате анализа определяется возможность получения пользователем записей, ему не принадлежащих; если это возможно, к запросу добавляется дополнительное условие, гарантирующее получение пользователем только его записей. Затем запрос отправляется на обработку в СУБД MySQL.

Ключевые слова

DBMS security, web applications, access control, безопасность СУБД, веб-приложения, управление доступом

Авторы

ФИООрганизацияДополнительноE-mail
Ткаченко Николай ОлеговичНациональный исследовательский Томский государственный университетаспирантn.o.tkachenko@gmail.com
Колегов Денис НиколаевичНациональный исследовательский Томский государственный университеткандидат технических наук, доцент кафедры защиты информации и криптографииd.n.kolegov@gmail.com
Всего: 2

Ссылки

Ткаченко Н. О. Реализация монитора безопасности СУБД MySQL в DBF/DAM-системах // Прикладная дискретная математика. Приложение. 2014. №7. С. 99-101.
Колегов Д. Н., Ткаченко Н. О., Чернов Д. В. Основные элементы разработки механизма мандатного управления доступом в СУБД MySQL на основе ДП-моделей // Безопасность информационных техологий. 2014. №3. С. 102-107.
Колегов Д. Н., Ткаченко Н. О, Чернов Д. В. Разработка и реализация мандатных механизмов управления доступом в СУБД MySQL // Прикладная дискретная математика. Приложение. 2013. №6. С. 62-67.
Девянин П. Н., Захаренков П. С. Способ реализации информационного потока по времени в операционных системах с мандатным управлением доступом через clipboard // Методы и технические средства обеспечения безопасности информации: материалы Юбилейной 20-й науч.-технич. конф. 27 июня-01 июля 2011г. СПб.: Изд-во Политехн. ун-та, 2011. С. 76-77.
CVE-2012-2122. https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2122
Oracle Database. Oracle Label Security. http://www.oracle.com/technetwork/database/ options/label-security/index.html
Trusted DBMS Rubix. http://rubix.com/cms
СУБД Линтер. http://linter.ru
 Неинвазивная реализация мандатного управления доступом в веб-приложениях на уровне СУБД | ПДМ. Приложение. 2015. № 8.

Неинвазивная реализация мандатного управления доступом в веб-приложениях на уровне СУБД | ПДМ. Приложение. 2015. № 8.