General method for HTTP Messages authentication based on hash functions in Web applications.pdf Одним из свойств, характеризующих безопасность протоколов, является свойство аутентификации сообщений, заключающееся в обеспечении аутентификации источника данных и целостности передаваемого сообщения. Аутентификация источника данных означает, что протокол обеспечивает гарантии того, что полученное сообщение или его части были созданы одним из участников протокола в некоторый момент времени, предшествующий получению сообщения, и что никакие данные не были модифицированы или подделаны. Считается, что аутентификация источника данных включает целостность данных [1]. В веб-приложениях аутентификация сообщений, которыми обмениваются клиент и сервер по протоколу HTTP, как правило, реализуется на уровне логики самого веб-приложения и позволяет обеспечить выполнение следующих свойств безопасности: - аутентичность источника HTTP-запроса; - целостность имен и значений параметров, переданных клиенту в HTTP-ответе в виде HTML; - целостность потока операций. Кроме того, аутентификация сообщений на основе криптографических методов защиты позволяет существенно повысить уровень защищённости веб-приложения, а также его стойкость к средствам автоматизированного анализа [2]. У известных механизмов аутентификации сообщений в веб-приложениях [3 - 7] можно выделить следующие недостатки: - отсутствует общая формальная модель безопасности механизма аутентификации сообщений; - разработанные методы, как правило, ориентированы на конкретное веб-приложение и часто не учитывают особенности криптографических протоколов (например, необходимость защиты от атак повтора или от утечек CSRF-токенов, необходимость использования уникальных токенов); - отсутствуют механизмы контроля целостности и валидации данных, генерируемых на клиентской стороне (например, данных, вводимых в поля форм). Аутентификация HTTP-сообщений рассматривается как элемент политики атрибутного управления доступом. На основе положений модели ABAC [8] строится общая модель аутентификации сообщений. Используются следующие обозначения: A - алфавит; A* - множество всех слов в A; [а] - множество букв слова а; x||y - конкатенация строк x и y; h - ключевая хеш-функция, построенная по алгоритму HMAC. Построим модель аутентификации HTTP-сообщений на основе модели ABAC. Основными элементами модели являются следующие: O - множество объектов; S - множество субъект-сессий; E = S U O - множество сущностей; OA - множество атрибутов объектов; SA - множество атрибутов субъект-сессий; EA = ES U EO - множество атрибутов сущностей; OP - множество операций (видов доступа); TA - множество всех типов атрибутов; SAV - множество значений атрибутов субъект-сессий; OAV - множество значений атрибутов объектов. В рамках модели ABAC будем считать HTTP-запросы пользовательскими субъект-сессиями; параметры и заголовки HTTP-запроса, идентификатор субъект-сессии (пользователя)-атрибутами субъект-сессии; элементы (scheme, authority, path) схемы URI HTTP-ресурсов - объектами; разрешённые параметры запроса, разрешённые идентификаторы пользователей, запрашивающих доступ к ресурсу, - атрибутами объекта; методы протокола HTTP - видами доступов. Будем также считать, что субъект-сессия имеет обязательные атрибуты key и time, а каждый объект имеет обязательный атрибут тас. Определим функции: - type : E ^ TA - функция, задающая тип атрибута; - ЕЕА : Е ^ 2oa U 2SA - функция, задающая множество атрибутов сущности; - ЕАТ : E х Т ^ 2oaU2sa - функция, задающая для сущности множество атрибутов данного типа; - АУ : Е х ЕА ^ SAF U OAF - функция, определяющая значение атрибута сущности; - assign_auth : O х 2EA х OP ^ SAF U OAF - функция, вычисляющая значение переменной de_jure_auth для соответствующей сущности-объекта и значение переменной de_facto_auth для сущности субъект-сессии. Пусть заданы множества S, O, ОА, SA, ТА, OP, EC, SAF, OAF и функции ЕЕА, ЕАТ, type, АУ и assign_auth. Определим предикат can_access(s, o, op), истинный тогда и только тогда, когда выполнены следующие условия: 1) для объекта o определен атрибут mac со значением АУ(o, mac) = h(AF(s, key), de_jure_auth, АУ(s,time)), где de_jure_auth = assign_auth(o, 2EEA(o),op); 2) выполнено равенство АУ(o,mac) = h(AF(s, key), de_facto_auth, АУ(s,time)), где de_f acto_auth = assign_auth(o, 2EEA(s), op). Назовём P = (can_access(s, o, op), assign_auth) политикой безопасности. Будем говорить, что HTTP-запрос s Е S на доступ op Е OP к ресурсу o Е O является аутентичным, если предикат can_access(s, o, op) является истинным. Определим политику безопасности P так, чтобы стало возможным обеспечить выполнение одного или нескольких свойств безопасности веб-приложений. Параметр (атрибут) q Е OA объекта o Е O называется контролируемым по значению, если политика безопасности обеспечивает выполнение условия АУ (o, q) = = АУ (s, q). Параметр q Е OA объекта o Е O называется валидируемым в алфавите А, если политика безопасности обеспечивает выполнение условия АУ(s,q) Е А*. Параметры типа t Е ТА называются контролируемыми по имени, если политика безопасности обеспечивает выполнение условия ЕАТ(o, t) = ЕАТ(s,t). Аутентификатором объекта o Е O будем называть значение de_jure_auth, вычисленное по атрибутам объекта o в соответствии с методом вычисления функции assign_auth. Аутентификатором субъект-сессии s Е S будем называть значение de_facto_auth, вычисленное по атрибутам субъект-сессии s в соответствии с методом вычисления функции assign_auth. В рамках предложенной модели опишем метод построения аутентификатора, обеспечивающего выполнение следующих требований политики безопасности: базовое управление доступом пользователя к ресурсам, контроль целостности имён параметров и их значений, валидация значений параметров в заданном алфавите. Идея метода заключается в построении аутентификатора - строки, содержащей конкатенацию всех контролируемых атрибутов субъект-сессии, объекта и метода доступа, - и последующем его использовании в криптографическом протоколе аутентификации сообщений. Метод. Условия применения метода: определены сущность e Е Е и функция assign_auth, задающая политику построения аутентификатора сущности. 1) Построить список L атрибутов сущности e, соответствующих параметрам. Перейти к его началу. 2) Если параметры из списка L являются контролируемыми по имени, то положить auth = auth||i1|| ... ||im, где {i1,... , im} - упорядоченное множество имён атрибутов и EAT(e, t) = {i1,... , im} для типа t, соответствующего типу «параметр». 3) Для каждого контролируемого по значению параметра l G L положить auth = = auth||l||AV(e,l) и удалить его из L. 4) Для каждого валидируемого параметра l G L положить auth = auth||l||([AV(e,l)]\ \ A) и удалить его из L. 5) Положить auth = auth||ids||idr||op, где idr -идентификатор объекта; ids - атрибут-идентификатор пользователя; op - метод доступа. 6) Выполнить протокол аутентификации сообщений, используя значение auth в качестве одного из его параметров. Данный метод аутентификации HTTP-сообщений может быть реализован на основе криптографических протоколов с ключевыми хеш-функциями. Особенности функционирования веб-приложений предъявляют следующие требования к протоколу: протокол должен быть прозрачен для клиента (нежелательна его реализация на клиентской стороне); протокол должен быть двухшаговым; протокол может быть реализован в рамках взаимодействия веб-браузера и веб-сервера. Параметры протокола: k - долговременный ключ сервера; kr - одноразовый случайный ключ сервера; idr - идентификатор защищаемого объекта; ids - идентификатор пользователя; time - текущее значение времени; Lp - запись политики P на некотором языке L. Действия протокола следующие: 1) Пользователь инициализирует отправку HTTP-запроса в рамках субъект-сессии s G S с атрибутом-идентификатором пользователя ids. 2) Сервер по полученному запросу формирует ответ, содержащий объект o G O; в соответствии с политикой безопасности P для объекта o вычисляет значение de_jure_auth, значения атрибутов mac = h(kr, de_jure_auth, time) и policy = = Ek(Lp, time,kr); отправляет значения policy и mac вместе с описанием объекта o в HTTP-ответе. 3) Пользователь в рамках субъект-сессии s отправляет запрос на доступ вида op G OP к объекту o вместе с атрибутами policy и mac. 4) Сервер по атрибутам субъект-сессии s получает значения LP, time и kr, вычисляет значение de_facto_auth, находит mac' = h(kr, de_f acto_auth, time), проверяет совпадение mac и mac', а также соответствие временной метки допустимому интервалу. Особенность базового протокола заключается в том, что никакие данные, кроме главного ключа k, на сервере не хранятся. Это позволяет реализовать stateless-меха-низм и обойтись без поддержки устойчивых (persistence) соединений и без хранения политики безопасности в общедоступной сессии (sharing session) при реализации протокола для веб-фермы.

Скачать электронную версию публикации