Современные информационные технологии/4. Информационная безопасность

Аспирант Токарчук А.М.

Московский государственный университет путей сообщения (МИИТ), Россия

Методика обеспечения безопасности веб-приложений

Обеспечение безопасности программного кода веб-приложения, данных хранимых в БД, а также инфраструктуры сервера является одной из важных проблем в веб-разработке. Существует множество методик обеспечения безопасности, основанных на фильтрации входных воздействий от клиента[1], а также нейросетевые методы анализа входных воздействий[2]. Основная задача средств безопасности – классификация входных воздействий по опасности для веб-приложения, с автоматической остановкой рабочего цикла в случае обнаружения опасных входных воздействий.

Для обеспечения безопасности веб-приложений предлагается методика двухступенчатой классификации входных воздействий. В веб-приложениях, большая часть входных воздействия направлена на одно из действий СЧМУ-множества = {создание, чтение, модификация, удаление} определённого ресурса, определяемое вектором управления {m,c,a}, где m – модуль, с – контроллер, a –функция (действие) контроллера. Соответственно, вектор управления {m,c,a}, а именно конкретное действие конкретного контроллера определённого модуля является объектом входного воздействия.

O = {m,c,a}

Для определения субъекта доступа, необходимо проанализировать входное воздействие на принадлежность его конкретному или анонимному пользователю и его роли rl, из множества ролей Rl:

Rl = {гость, пользователь, директор, менеджер, администратор}

Множество ролей определено предметной областью веб-приложения, однако в любом веб-приложении будут присутствовать роли из обязательного списка ролей Rl_min.

Rl_min = {гость, пользователь, администратор}

Расширенное некотором непустым множеством ролей предметной области[3] Rl_пр.обл., которое в данном примере определяется как:

Rl_пр.обл. = {директор, менеджер}

Роль пользователя (rl), а также его идентификатор (id) составляют характеристики субъекта воздействия S.

S = {rl_S, id_S}

В соответствии с этим определяется множество правил Rul, разрешающих, или запрещающих доступ субъекта воздействия к объекту воздействия. Правило определяется следующим образом:

ru= {id, {m,c,a}, {comp, comp_owner_key, comp_group_key}, Allows},

где id – уникальный идентификатор правила,

{m,c,a} – вектор управления, характеризующий объект правила,

{comp, comp_owner_key, comp_group_key} – вектор связи вектора управления с конкретным экземпляром модели предметной области,

· Comp – название класса модели

· Comp_owner_key – название внешнего ключа модели объекта правила к субъекту правила по индивидуальной политике доступа (обычно равен “user_id”)

· Comp_group_key – Название внешнего ключа модели объекта правила к субъекту правила по групповой политике доступа (обычно “group_id”)

Allows – вектор значений разрешений. Тип значений – значение из троичной логики, где 0 – доступ запрещён, 1 – доступ разрешен, NULL (пустое множество, ничто) – не имеет значения.

Результат операции проверки доступа по данным объекта доступа(O), субъекта доступа(S) и массиву правил доступа(R) составляет число в двоичном формате соответствующее результату проверки всех правил, применённых к данному вектору управления {m,c,a}. Проверка доступа может следовать одной из двух стратегий проверки: стратегии разрешений (всё, что не разрешено – запрещено) или стратегии запрещений (всё, что не запрещено – разрешено). При использовании стратегии разрешений, перед проверкой правил устанавливается запрет доступа, а затем в цикле по ним ищутся разрешения. При использовании стратегии запрещений, перед проверкой правил устанавливается разрешение доступа, и ищутся запрещения.

Рисунок 1. Определение области применения в правилах доступа

Вектор управления в правилах доступа может задаваться частично (см. Рис 1). Возможны ситуации отсутствия правил для данного вектора {m,c,a} – Рис 1.а,определения правила только для модуля (общие правила модуля) – Рис 1.б, определение правил для конкретного контроллера (Рис. 1.в), или конкретного действия (Рис. 1.г). Чем полнее определено правило доступа (приоритет от последнего к первому на Рис. 1) тем позже будет применяться правило. Очередность применения правил доступа влияет на конечный результат, т.к. правила перезаписывают результат проверки предыдущих, т.е. при наличии правила определённого для конкретного действия, остальные в расчет приниматься не будут. Это позволяет минимизировать количество правил доступа при максимизации покрытия всех действия контроллеров (а значит и программного кода) правилами. Минимальное количество правил в веб-приложении равно мощности множества модулей М веб-приложения (т.е. числу модулей в нём).

Максимальное количество правил в веб-приложении (без учёта дополнительных обработчиков вне приложения) определяется по следующей формуле:

Где M – множество модулей веб-приложения,

С_m – множество контроллеров модуля “m”,

A_c – множество функций-действий контроллера “c”.

При этом, если используются только СЧМУ-действия для ресурсов моделей, то:

т.к. СЧМУ-контроллеры содержат только 7 действий (отображение списка моделей, отображение экземпляра модели, сохранение данных формы новой модели, сохранение данных формы редактирование модели, удаление модели, форма новой модели, форма редактирования модели). Функция проверки правил, выполняет каждое правило из стека (в который оно было загружено в порядке “FIFO” функцией загрузки правил из БД) над объектом и субъектом правила. Она выполняет двухступенчатую классификацию, которая состоит в определении “ролевого” доступа, и “группового+индивидуального” доступа.

Определение возможности “ролевого” доступа заключается в бинарной классификации входных воздействий на разрешенные и запрещённые, на основе роли субъекта доступа, а также объекта доступа (вектору {m,c,a}). При этом может быть вынесено как положительное, так и отрицательное решение о доступе.

,

Где rl(S)_allow – значение атрибута “_allow” правила для соответствующей роли пользователя.Условие применение ролевого доступа следующее:

В базе данных записывается, как NULL-значение. NULL — специальное значение (псевдозначение), которое может быть записано в поле таблицы базы данных (БД). NULL соответствует понятию «пустое поле», то есть «поле, не содержащее никакого значения». Введено для того, чтобы различать в полях БД пустые (визуально не отображаемые) значения (например, строку нулевой длины) и отсутствующие значения (когда в поле не записано вообще никакого значения, даже пустого).

Определение “группового+индивидуального” доступа заключается в бинарной классификации входных воздействий на основе возможности доступа самого субъекта, конкретного пользователя (на основе атрибута “comp_owner_key” правила), входящего в конкретную группу (на основе атрибута “comp_group_key” правила) к конкретному объекту (на основе атрибута “comp” правила + атрибута “id” входного воздействия), над которым производится СЧМУ-действие в функции-действии класса контроллера. Значение функции “группового+индивидуального” доступа имеет приоритет над функцией “ролевого” доступа.

Где C = {comp, owner_k,, group_k}, S = {rl_S, id_S}

Условие применения “группового+индивидуального доступа” следующее:

Таким образом, определение функции доступа для одного правила будет следующее:

Функции контроля доступа выполняются после загрузки приложения, но до начала рабочего цикла. Такой порядок выполнения позволяет не тратить вычислительные ресурсы на цикл обработки входных воздействий от пользователей, доступ для которых закрыт.

Литература:

1. Токарчук А.М. Применение средств ORM для разработки безопасных веб-приложений / А.М. Токарчук // Безопасность информационных технологий.- 2010 – N1.- C.113-115.

2. Барский А.Б. Нейронные сети: распознавание, управление, принятие решений. – М. Финансы и статистика, 2004. – 176с.

3. Токарчук А.М. Паттерн для отражения бизнес-логики / А.М. Токарчук // Мир транспорта – 2010 – N2.-C.114-118