Non-invasive integrity control method for cookie in web applications.pdf Термином cookie в протоколе HTTP обозначается набор данных, хранимый веб-клиентом (веб-браузером) и отправляемый на сервер в специальном заголовке Cookie в HTTP-запросах. Cookie первоначально могут быть сгенерированы на веб-сервере и переданы веб-клиенту в заголовке Set-Cookie в HTTP-ответе либо сгенерированы на стороне веб-клиента с помощью переданного веб-сервером Javascript. Cookie, как правило, используются веб-приложением для идентификации и аутентификации пользователей, а также для хранения произвольных данных, настроек и т. п. Таким образом, если веб-приложение имеет уязвимость, связанную с недостаточной обработкой данных, передаваемых в cookie (например, уязвимость к атаке внедрения операторов SQL), то злоумышленник может модифицировать полученные cookie для эксплуатации данной уязвимости. Примеры атак на веб-приложения через механизм cookie описаны, например, в [1]. Одним из методов защиты от атак на веб-приложения является использование ключевых хеш-функций для аутентификации HTTP сообщений. Первоначально данный метод использовался лишь для контроля целостности атрибутов HTML (например, атрибутов href, src, action) и полей форм [2, 3]. В работе [4] метод обобщён и показано, как он может быть применён для защиты веб-приложений от широкого класса атак (например, CSRF, утечка токенов, HPP и др.). Одним из достоинств данного метода является возможность его неинвазивной реализации на уровне веб-приложения - реализации, не требующей изменения исходного кода веб-приложения. Ввиду существенных отличий в структуре данных и принципах функционирования механизма cookie метод [4] не может быть применен к последнему в том же виде. В данной работе исследуется возможность неинвазивного контроля целостности cookie на основе хеш-фунций. Структура данных cookie может быть представлена в виде набора c = (kc,vc,pc, dc, ec, fc), где kc - ключ (имя cookie); vc - значение cookie; pc - значение атрибута path; dc - значение атрибута domain; ec - значения атрибута expires; fc - список флагов (например, secure - передача cookie возможна только по HTTPS; session - cookie является сессионной; httpon/y - доступ к cookie средствами Javascript запрещён). При установке cookie веб-сервер отправляет веб-клиенту в заголовках HTTP-отве-та весь необходимый набор атрибутов, которые сохраняются веб-клиентом, после чего больше никогда не отправляются в HTTP-запросах к серверу. Таким образом, обеспечение целостности всех атрибутов cookie представляется более сложной задачей, чем тривиальное хеширование всех контролируемых атрибутов. Алгоритмы обеспечения целостности cookie, предложенные в [5], решают данную задачу лишь частично, обеспечивая целостность только для значения cookie и времени жизни. Подходы, описанные в работах [6, 7], решают задачи, связанные c реализацией защищённого контейнера на основе cookie для «sessionless»-веб-приложений. Предлагаемый метод контроля целостности cookie обладает следующими свойствами: - обеспечение целостность значения cookie; - защита cookie от удаления или продления, т. е. от изменения атрибута expires или установки флага session; - обеспечение целостности значений атрибутов path и domain; - контроль передачи cookie по защищённому соединению при установленном флаге secure; - возможность неинвазивной реализации. Будем использовать следующие обозначения: x|y - конкатенация строк x и y; hmac - ключевая хеш-функция, построенная по алгоритму HMAC; hmac(k,s) -результат применения алгоритма hmac с ключом k к строке s. Пусть C - множество всех cookie, используемых веб-приложением, а S С C - множество защищаемых (контролируемых) cookie. Для каждой защищаемой cookie c = (kc, vc,pc, dc, ec, /c) G S построим парную ей cookie c_s = (ks, vsds, es, /s), где: 1) es - максимально возможное значение, что позволяет получать из cookie c актуальную информацию о cookie c_s, даже если последняя устарела; 2) = pc и ds = dc, что обеспечивает одновременную отправку веб-клиентом cookie c и c_s до истечения времени expires; 3) vs = hmac(k, vc|ec)|ec, где k - ключ, уникальный для каждой сессии веб-приложения; данное построение позволяет контролировать целостность значений vc и ec и, кроме того, проверять, не истекло ли время жизни cookie c; 4) / = /с U (httpon/yj. Аутентификатором множества S будем называть строку auth, полученную конкатенацией значений kc,pc, dc, /с для всех cookie c из S. Для определения легитимности отправки каждой защищаемой cookie по значениям атрибутов path и domain дополнительно введём вспомогательную cookie а = = (ka,va,pa,da,ea,/a), в которой: 1) va = hmac(k, auth)|auth, где auth - аутентификатор S; 2) pa и da выбираются наиболее общими для рассматриваемого веб-приложения, что гарантирует отправку cookie а при любом запросе к веб-севрверу; 3) ea - максимально возможное значение; 4) /а = (httpon/yj. Рассмотрим основные действия протокола взаимодействия веб-клиента и веб-сервера. При первом запросе к веб-серверу пользователю устанавливается а с некоторым начальным значением. Все последующие запросы к веб-приложению обрабатываются в соответствии с приведённым ниже методом. Если в ответе веб-сервера устанавливается одна или несколько защищаемых cookie, то для каждой такой cookie c в HTTP-ответ добавляется заголовок Set-Cookie, устанавливающий парную ей cookie c_s, а данные о c заносятся в а. После обработки всех защищаемых cookie в HTTP-ответе значение hmac в а пересчитывается и в HTTP-ответ добавляется заголовок Set-Cookie, устанавливающий обновлённую а. При необходимости выставляются заголовки, удаляющие отмеченные на удаление cookie. Метод обработки запроса к веб-приложению Условия применения метода: задано множество S защищаемых cookie веб-приложения. Для каждого HTTP-запроса h выполнить следующие шаги: 1) Если в HTTP-запросе h отсутствует cookie а, то удалить из запроса h все защищаемые cookie c S и отправить модифицированный запрос h веб-серверу. 2) Проверить целостность значения cookie а. Для этого по значению va вычислить hmac' = hmac(k, auth'). При несовпадении hmac' и hmac запрос следует считать запрещённым. 3) Удалить из запроса h все защищаемые cookie c S, которые отсутствуют в а. 4) Для каждой защищаемой cookie c S, присутствующей в запросе h, проверить выполнение следующих условий: а) запрос h содержит для c парную cookie c_s; б) атрибут pc, полученный из cookie а, допускает отправку cookie c в запросе h; в) атрибут dc, полученный из cookie а, допускает отправку cookie c в запросе h; г) для cookie c с флагом secure запрос h передан по HTTPS; д) выполняется равенство vs = hmac(k, vc|ec) и ec меньше текущего времени. При невыполнении любого из условий запрос следует считать запрещённым. 5) Пометить на удаление все cookie c_s, для которых в запросе h отсутствуют парные им cookie c. В случае, если HTTP-запрос к веб-приложению признан запрещённым, его обработка приложением может привести к эксплуатации уязвимости, а потому нежелательна. В связи с этим предлагаются следующие варианты обработки таких HTTP-запросов: 1) Блокирование HTTP-запроса. 2) Перенаправление пользователя на некоторый URL-адрес. 3) Завершение сессии пользователя веб-приложения путём отправления на вебсервер специального HTTP-запроса и последующего удаления парных cookie и выставления начального значения cookie а. 4) Модификация HTTP-запроса путём удаления из него всех некорректных cookie и последующей отправки этого запроса на веб-сервер. Таким образом, описанный метод контролирует целостность всех атрибутов cookie, защищает их от несанкционированного удаления на клиентской стороне, позволяет определить необходимость отправки cookie на заданный путь и домен веб-приложения, а также обеспечивает аутентичность cookie. В то же время данный метод предполагает добавление |S| + 1 дополнительных cookie. Количество последних можно существенно сократить, отказавшись от введения парных cookie и вычисляя значение va следующим образом: va = hmac(k, m) |m, где m - строка, полученная конкатенацией значений domain^, pathj, hmacj. Значение hmacj = hmac(k,mij-), где m^ -конкатенация значений kc и vc для всех cookie c, которые могут быть отправлены на домен domain и путь pathj. В данном варианте реализации для всех защищаемых cookie c G S должны быть известны pc и dc. В этом случае обработка HTTP-запроса h происходит следующим образом: 1) Если в HTTP-запросе h отсутствует cookie а, то удалить из запроса h все защищаемые cookie c S и отправить модифицированный запрос h веб-серверу. 2) Проверить целостность значения cookie а. Для этого по значению va вычислить hmac' = hmac(k,m'). При несовпадении hmac' и hmac запрос следует считать запрещённым. 3) Вычислить hmac(k, m)' для v^,, используя для формирования m значения защищаемых cookie, полученных в h. При несовпадении hmac(k,m)' и соответствующего текущему пути и домену значения hmacj в va запрос следует считать запрещённым. Обработка HTTP-ответа происходит следующим образом: 1) Если HTTP-запрос был запрещён, то выставить в ответе заголовки, удаляющие на стороне клиента все защищаемые cookie c S и а. 2) Если в HTTP-ответе присутствуют заголовки, устанавливающие защищаемые cookie, то следует обновить значение hmacj для всех пар (domain^; pathj), соответствующих текущему пути и домену. Данный метод обеспечивает целостность значений cookie, требует меньшего количества служебных cookie, но накладывает следующие существенные ограничения на веб-приложение: - невозможность выставления cookie c с атрибутами path и domain, отличными от пути и домена HTTP-запроса, в котором выставляется cookie c; - невозможность пересчёта значения hmac по истечении времени жизни или при удалении cookie; - инициализация новой сессии при любом некорректном запросе. Реализация данных методов не требует изменения исходного кода веб-приложения и может быть выполнена на уровне гибридных WAF (например, ModSecurity), модульных фрэймворков (например, Django, Ruby on Rails) и сетевых WAF (например, F5 BIG-IP ASM). Прототип системы, реализующей эти методы, разработан на базе Django Middleware [8].

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