Масштабируемая система аутентификации для веб-приложений
Авторы: Кулаков В.В., Губенко Н.Е., Чернышева А.В.Источник: Підсумкова науково-практична конференція Всеукраїнського конкурсу студентських наукових робіт з природничих, технічних та гуманітарних наук у 2012/2013 навчальному році галузь знань «Інформаційна безпека»
Введение
На данный момент в сети интернет насчитывается более 600млн. ресурсов[1]. Большая часть из них использует различные процедуры аутентификации и авторизации для своих пользователей. Большие интернет-порталы требуют постоянного контроля со стороны администраторов и модераторов, также пользователи постоянно наполняют такие ресурсы новым содержимым, контентом. Различные группы пользователей имеют различные права доступа, связанные в основном с их ролью в жизни проекта (например, администраторам необходим практически полный доступ к управлению ресурсом, тогда как модераторам достаточно возможности добавлять, удалять и редактировать материалы). Проблема защищенности аутентификации пользователей появилась достаточно давно и ее актуальность постоянно растет. Разработано множество средств для проведения аутентификации в веб-среде, некоторые из которых довольно надежны но и достаточно дороги, другие - наоборот, практически не требуют ресурсов для поддержания функционирования, однако предоставляют недостаточный уровень защиты. Данная работа посвящена разработке программной системы для аутентификации пользователей, сочетающей в себе основные достоинства "дорогих" методов, но требующей гораздо меньше финансовых ресурсов.
Существующие схемы аутентификации, проблемы связанные с ними и методы их решения.
Существует множество схем аутентификации. Некоторые из них просты в реализации и практически не требуют финансовых ресурсов при эксплуатации. Однако, такие схемы не обеспечивают должного уровня защищенности приватной информации, они бессильны перед множеством видов атак (например атаки man in the middle). Другие схемы, например использование SSL, позволяют достаточно надежно защищаться от большинства видов атак, но требуют регулярных финансовых затрат (в случае с SSL это затраты на покупку и продление сертификатов). Исходя из особенностей конкретного веб-проекта следует делать выбор между защищенностью информации и экономическим аспектом. Разрабатываемая в рамках данной работы система Asgardian_Gate должна дать возможность небольшим проектам с ограниченным бюджетом использовать достоинства систем аутентификации на основе протокола SSL, при этом значительно снизив финансовые расходы на содержание системы аутентификации. Возможная схема применения Asgardian_Gate может выглядеть следующим образом. Имеется несколько (например 10) развивающихся веб-проектов, для каждого из которых необходимо обеспечить достаточно надежную систему аутентификации пользователей. Бюджет этих проектов ограничен. Предположим, куратор данных проектов предпочтет использовать SSL сертификаты для каждого из них. Тогда придется ежегодно оплачивать стоимость десяти сертификатов при том, что прибыль от этих проектов на ранних этапах развития крайне мала. Если же в подобной ситуации использовать систему Asgardian_Gate, то для всех десяти ресурсов потребуется всего один SSL-сертификат и один сервер (возможно использование недорогого виртуального хостинга), выполняющий роль сервера аутентификации. Очевидно, экономический эффект от внедрения такой системы весьма ощутим, особенно для небольших организаций.
Рассмотрим простейшую процедуру аутентификации пользователей. В БД хранятся пары логин-пароль, причем логин - уникальный идентификатор (точнее, его текстовое представление), принадлежащий конкретному пользователю. Чтобы получить определенные права доступа к ресурсу, пользователь должен представиться своим именем, которое является публичной информацией и не скрывается от других пользователей. Для того, чтобы доказать, что пользователь является именно тем за кого себя выдает, он должен ввести пароль, который известен только ему и системе аутентификации ресурса. В рассматриваемом нами случае, логин и пароль передаются по сети в открытом виде, и при прослушивании трафика злоумышленник получает учетные данные жертвы (которая об этом может и не догадываться), а вместе с тем и права доступа. Также если злоумышленник завладеет копией базы данных ресурса (например методами промышленного шпионажа), то он получит доступ к учетным данным всех пользователей системы. Данная проблема усугубляется еще и тем, что многие пользователи используют для различных сервисов одинаковые имена и пароли, так что завладев БД одного ресурса (например, портала любителей французской выпечки), злоумышленник может получить доступ к аккаунтам таких пользователей на других ресурсах (например, почтовых сервисах или банковских сайтах с возможностью управления счетами). Подобная схема является наименее защищенной, поэтому на данный момент практически не используется. Последняя проблема решается применением хеширования. Т.е. в базе данных хранится не сам пароль, а результат работы однонаправленной хеш-функции, по которой восстановить секретную информацию достаточно сложно.
Пользователь передает свой пароль, от которого на сервере вычисляется хеш. Результат сравнивается со значением той же хеш-функции от пароля пользователя, полученным при регистрации. Если эти значения совпали - значит пользователь передал верный пароль.
Таким образом, при несанкционированном доступе к БД ресурса, учетные данные пользователей некоторое время будут оставаться в безопасности (пока злоумышленник не получит исходные значения по хешам паролей). Это время следует использовать для оповещения пользователей, которые в свою очередь должны сменить скомпрометированные пароли. Такая схема аутентификации также является довольно небезопасной, однако в силу своей простоты часто используется ресурсами, не требующими высокого уровня защиты информации. Опасность перехвата пароля при передаче в данной схеме очень велика.
Анализ структуры и особенностей протокола SSL
Основная проблема методов, рассмотренных выше состоит в следующем. Чтобы передать данные на сервер, необходимо их зашифровать. Но для этого необходимо знать ключ для шифрования, который сначала необходимо передать по тому же соединению. Для решения этой проблемы можно использовать протокол SSL. SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS. Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причём для шифрования используется асимметричный алгоритм с открытым ключом. Подробное описание протокола и деталей его реализации в данной работе приводить не имеет смысла, рассмотрим общую концепцию аутентификации с использованием SSL. Наиболее значимая особенность SSL - использование третьей (доверенной) стороны. Т.е. клиент получив от сервера открытый ключ для шифрования, сначала должен проверить, действительно ли данный открытый ключ выдан целевым сервером. Если это так, то закрытый ключ для расшифровки сообщения также имеется только у того сервера, которому предназначается секретная информация. Чтобы осуществить такую проверку, сервер обращается к центру сертификации и подписывает свои публичные ключи с помощью ЭЦП. Клиент, получив публичный ключ сервера, обращается к третьей стороне (центру сертификации), с помощью которого проверяет ЭЦП, прикрепленную к этому ключу.
Если проверка ЭЦП завершается успешно, то клиент может передавать данные, шифруя их полученными открытыми ключами. На клиентской стороне проверкой сертификатов сервера как правило, занимается браузер. Естественно, хранить на пользовательских машинах сертификаты для всех сертифицированных доменов невозможно. Поэтому, в локальных хранилищах содержатся только сертификаты центров сертификации, служащие для установления безопасного соединения с центром. Содержание центров сертификации требует значительных ресурсов. Соответственно, получение заверенного SSL сертификата, который будет приниматься всеми наиболее распространенными браузерами, стоит определенную сумму денег ежегодно. Для крупных коммерческих проектов цена такого сертификата не станет обременительной, но для молодых развивающихся ресурсов она может оказаться весьма ощутимой.
Разработанная программная система Asgardian_Gate
Цель разрабатываемой системы - обеспечить безопасное проведение передачи наиболее важной информации (пароли и т.д.) от клиентов к серверам и обратно, минимизировав при этом регулярные финансовые затраты. Основная идея - использовать для установления защищенных соединений для множества ресурсов отдельный (один) сервер, имеющий SSL-сертификат. Таким образом, имея лишь один заверенный сертификат, система Asgardian_Gate позволяет множеству ресурсов устанавливать защищенные соединения со своими пользователями. Перед тем, как запросить у пользователя важную секретную информацию (например, пароль), информационный сервер должен отправить пользователя на страницу, содержащую форму входа. Эта страница расположена на сервере аутентификации. На данном этапе пользователь может быть уверен, что документ получен из достоверного источника (HTTPS протокол в адресной строке браузера) и информация, которая отображается в браузере - не была модифицирована злоумышленником. Заполнив форму, пользователь отправляет данные информационному серверу по незащищенному каналу, но уже в зашифрованном по алгоритму RSA виде, что обеспечивается системой Asgardian_Gate. Дополнительно, при переходе с севера аутентификации на информационный сервер, пользователь может активировать режим "защищенная зона", в котором поддерживается безопасное соединение даже при просмотре страниц информационного сервера, не имеющего собственного сертификата. Этот режим необходим, если нужно обеспечить безопасность не только той информации, которая передается от клиента серверу, но и той, которая приходит от сервера обратно к клиенту. Функционирование "защищенной зоны" осуществляется средствами совместно работающего серверного и клиентского ПО. Так как этот режим накладывает некоторые (не критичные) ограничения на использование информационного ресурса (в основном ограничения касаются стандартных навигационных опций браузеров), предполагается возможность отключения данного режима для более комфортного просмотра страниц, информация на которых не является конфиденциальной.Принципы утентификации
Рассмотрим подробнее механизм аутентификации с использованием системы Asgardian_Gate. Последовательность действий, происходящая при передаче учетных данных показана на рисунке 1.
Рисунок 1 - Диаграмма последовательности зашифровывания и передачи учетных данных
При необходимости пройти процедуру аутентификации, пользователь перенаправляется информационным сервером на сервер аутентификации. Вместе с перенаправлением, серверу аутентификации передается идентификатор информационного сервера (каждый информационный сервер в системе Asgardian_Gate имеет свой уникальный идентификатор). С этим идентификатором связан URL-адрес сервера и ключи, необходимые для зашифрованной передачи данных между сервером аутентификации и информационным сервером. Установив зашифрованное соединение с информационным сервером, сервер аутентификации запрашивает у него набор ключей для установления зашифрованного соединения между клиентом и информационным сервером. Получив эти ключи, сервер аутентификации передает их клиентскому ПО. Введя свои учетные данные, пользователь инициирует отправку данных на информационный сервер (используя кнопку "Войти"). Клиентское ПО шифрует эти данные открытым ключом и передает шифротекст информационному серверу. Информационный сервер дешифрует полученные данные закрытым ключом, вычисляет хеш от дешифрованного значения пароля пользователя и выполняет поиск по таблице пользователей. если найдена запись, для которой логин и хеш пароля совпадают с данными, полученными от пользователя, процедура аутентификации считается успешно завершенной. Последующее поддержание активной сессии пользователя может основываться как на стандартных средствах, так и на механизме "защищенной области" системы. Таким образом используя систему Asgardian_Gate для серверов, не имеющих своего сертификата, реализуется процедура аутентификации, при которой секретные данные не передаются в открытом виде и так же нет необходимости хранить в базе данных пароли в открытом виде.
Защищенная область
После отправки зашифрованных данных серверу, пользователь перенаправляется на информационный сервер. Так как соединение с этим сервером изначально не защищенное, то есть вероятность атаки man in the middle с целью модификации данных, передаваемых пользователю. Например, злоумышленник может встроить в передаваемый документ вредоносный клиентский код, при выполнении которого может быть нарушена конфиденциальность данных пользователя. Также возможна атака, направленная на перенаправление запроса серверу злоумышленника. Режим "защищенная область" системы Asgardian_Gate создан для минимизации риска проведения атак подобного рода. Для перехода в этот режим, сервер аутентификации отправляет пользователю клиентский код, который работая совместно с соответствующими модулями серверного ПО, обеспечивает функционирование "защищенной области". Суть механизма в следующем. клиентский код перехватывает все попытки пользователя перейти по ссылкам, размещенным на текущей странице. При возникновении такого события, клиентский модуль генерирует случайным образом тестовую строку и шифрует ее открытым ключом. Далее осуществляется AJAX-запрос по адресу, указанному в ссылке (по которой собирался перейти пользователь) но к нему добавляются в качестве параметров флаг работы в режиме "защищенной области" и зашифрованное значение тестовой строки. В результате выполнения такого запроса, ответ сервера (или модифицированные злоумышленником данные) не выполняются сразу же на клиентской стороне, а сохраняются в строковую переменную. При получении запроса с флагом работы в режиме "защищенной области", сервер дешифрует тестовую строку своим закрытым ключом и зашифровывает своим ключом для шифрования. Результат дописывается в конец сгенерированного документа и происходит отправка данных клиенту. Также клиенту передается хеш от сгенерированного сервером документа. Получив ответ сервера, клиентский модуль защиты дешифрует ту часть сообщения, в котором должна содержаться тестовая строка. Если значения изначально сгенерированной строки и дешифрованного ответа сервера совпадут - значит документ действительно сгенерирован целевым информационным сервером. В таком случае, тело текущей страницы заменяется содержимым строки, содержащей ответ сервера. Таким образом возможно защитить пользователя от атаки перенаправления. Для защиты от атаки модификации документа, серверу необходимо вместе с ответной тестовой строкой передать клиенту в зашифрованном виде также хеш от сгенерированного документа. В таком случае при модификации злоумышленником данных, клиентский модуль сможет обнаружить несоответствие полученных данных и значения хеша, переданного сервером в зашифрованном виде. Также полезным может оказаться выполнение шифрования всего документа каким-либо симметричным алгоритмом и передача ключа для такого шифрования вместе с хешем и ответной строкой в зашифрованном асимметричным алгоритмом виде. При функционировании системы в режиме "защищенной области", как такового перехода по ссылкам не осуществляется. Как было сказано выше, клиентский модуль только переписывает код страницы. С этим связаны некоторые ограничения. Например, стандартная для большинства браузеров функция "вернуться назад" может работать с ошибками. В режиме "защищенной области" данной функцией пользоваться не рекомендуется. Приведем пример работы системы в таком режиме При нажатии на соответствующую кнопку, пользователь будет перенаправлен на сервер аутентификации для ввода секретных данных или входа в режим "защищенной области".Если не ввести учетные данные, авторизация проведена не будет, но защищенный режим будет активирован. На странице сервера аутентификации присутствует фрейм, содержащий специальную страницу информационного сервера, на которую и происходит первоначальная установка ключей и клиентского модуля защиты. В силу того факта, что в режиме "Защищенная область" не происходит непосредственного перехода по ссылкам, в окне браузера подсветка посещенных ссылок отображается не совсем корректно.
По той же причине при открытии очередной страницы в режиме "защищенной области", содержимое адресной строки браузера не изменяется. Система Asgardian_Gate спроектирована таким образом, чтобы ее можно было применять на уже функционирующих ресурсах с минимальными изменениями в коде проекта.
Например ссылки, используемые на страницах информационных серверов вручную модифицировать не следует. Клиентский модуль защиты самостоятельно справится с их обработкой. Если при переходе по очередному адресу, клиентский модуль обнаружит неверный ответ сервера на запрос защищенного режима, пользователю будет выведено сообщение, вида как показано на рисунке 2 (Страница page2.php умышленно сделана с поврежденным серверным модулем поддержки безопасного режима).
Рисунок 2 - Предупреждение о выходе из "защищенной области"
Технические особенности реализации программной системы
Систему Asgardian_Gate можно условно разделить на 3 части, ПО сервера аутентификации, ПО информационных серверов и клиентское ПО.
Серверные модули реализованы на языке программирования PHP, а клиентские - на JavaScript.
Для зашифровывания передаваемой информации используется алгоритм RSA, длина ключа - 512бит.
В проекте использовались библиотеки, реализующие данный алгоритм шифрования и распространяемые по свободной лицензии. Так, реализация серверного модуля RSA - библиотека Crypt_RSA, ее автор - Jim Wigginton Доступ к локальному хранилищу имеют только скрипты, содержащиеся на странице из того же домена, к которому привязано это хранилище.
Т.е скрипты, расположенные на странице ввода учетных данных, которая находится на сервере аутентификации, не могу напрямую записывать и считывать данные из локального хранилища, привязанного к домену информационного сервера.
Также политика безопасности браузеров не позволяет кросс-доменные обращения к JavaScript - переменным и функциям, даже если одна из страниц загружена во фрейм внутри другой.
Для решения этой проблемы были использованы специальные возможности HTML5.
В стандарте HTML5 предусмотрена отсылка javascript-сообщения из одного окна в другое при помощи специального вызова window.postMessage.
При этом окна могут быть с любых доменов, не важно. Например, один iframe с yandex.ru , а другой - с vaysapupkin.info. Чтобы получать кросс-доменные сообщения, принимающее окно регистрирует специальный обработчик onmessage, в котором, кроме всего прочего, может проверить, с какого домена пришло сообщение.
Реализация postMessage браузерами использует внутренний механизм передачи сообщений, поэтому можно передавать любые объекты, а сам факт передачи никак не отслеживается снифферами пакетов. Интерфейс поддерживается основными современными браузерами.
Используя механизм postMessage удалось добиться безопасной и быстрой передачи ключей со страницы сервера аутентификации в хранилище страницы, принадлежащей информационному серверу.
Перед тем как начать передачу ключей фрейму, необходимо убедится, что он полностью загружен и код, содержащийся в нем уже работает. Для этого в код фрейма добавлена функция, которая отправит сообщение родительскому окну когда фрейм будет загружен.
Получив такое сообщение, родительское окно отправит отправит ответное сообщение фрейму. В этом сообщении уже будут содержаться ключи, которые необходимо сохранить в локальном хранилище фрейма.
Так как браузер IE поддерживает передачу через postMessage только строковой информации (другие браузеры позволяют передавать и объекты), то набор ключей, представленный в JSON-формате, необходимо перевести в строковое представление перед отправкой, а при извлечении этих данных из локального хранилища, - провести обратное преобразование.
Диаграмма последовательности действий при функционировании программной системы в режим "защищенная область" приведена на рисунке 3.
При передаче данных по незашифрованному соединению, сама информация шифруется асимметричным алгоритмом. Для шифрования передачи от клиента к серверу и от сервера клиенту используются два набора ключей.
Диаграмма состояний при функционировании системы в данном режиме показана на рисунке 4.
Система Asgardian_Gate, разрабатываемая в рамках данного проекта, показала работоспособность самой идеи функционирования систем защиты подобного рода. В данный момент программная система способна защищать данные, передаваемые пользователем серверу от прослушивания и подмены трафика, что и было основной целью проекта. Однако некоторые дополнительные функции все еще предстоит реализовать.
Например, полное шифрование контента, передаваемого от информационных серверов клиентам. Данная возможность не являлась приоритетной при создании проекта, но будет очень полезной при реальном использовании системы. К тому же, реализация данной функциональности на основе уже имеющихся модулей будет довольно тривиальной задачей.
Недостатком системы на данный момент является отсутствие схемы смены паролей для асимметричного шифрования. Реализация решения этой проблемы также не является сложной задачей.
Также к недостаткам системы можно отнести те ограничения, которые накладываются использованием режима "защищенной области".
На данный момент разработанная программная система поддерживает последние версии браузеров FireFox, Opera и IE.
Разработана программная система, позволяющая использовать преимущества протокола SSL на множестве информационных серверов, при этом сократив финансовые расходы до уровня, необходимого для содержания одного такого сервера с классической схемой защиты, основанной на использовании SSL.
Система показала возможность своего применения на реальных проектах, в которых требуется надежная система защиты данных при передаче, но бюджет которых ограничен.
В обозримом будущем планируется внедрение данной системы в тестовом режиме для окончательного тестирования стабильности и удобства ее использования.
Система Asgardian_Gate, разрабатываемая в рамках данного проекта на данный момент содержит реализацию большинства запланированных модулей. Однако некоторая часть функционального наполнения все еще ожидает завершения.
Преимущества веб хранилищ:
Рисунок 3 - Диаграмма последовательности функционирования системы в режиме "Защищенная область"
Рисунок 4 - Диаграмма состояний системы при функционировании в режиме "защищенная область"
Достоинства и недостатки разработанной программной системы
Заключение
Список литературы