Оценка: управление нечетным сеансом в веб-приложении

Question

Я искал устаревшее приложение с веб-интерфейсом пользователя. Учитывая его возраст (около 10 лет на некоторых частях), многое нуждается в обновлении и повторной архитектуре, но мне интересно узнать о том, как работают пользовательские сессии.

В двух словах:

• Весь интерфейс подается через HTTPS.
• Пользователи аутентифицируются незаметно, сравнивая хеш имени пользователя и пароля со значениями, сохраненными в базе данных.
• После аутентификации установлен куки-файл браузера, который содержит два значения, которые сохраняют последний раздел/модуль верхнего уровня и второго уровня, к которому пользователь имел доступ, дату истечения срока действия и значение, подобное «loggedin = true ». При выходе из системы cookie сбрасывается с «loggedin = false». В cookie нет токена сеанса.
• Первая страница загружается после аутентификации, а также каждая последующие загрузки страницы, содержит переменную JavaScript «sessionToken», который представляет собой в кодировке base64 строки с различными частями, некоторые из которых шифрованных: var sessionToken = "...."
• Каждого звено навигации генерирует HTTP POST-запрос через элемент <form> и обработчики событий JavaScript с соответствующими переменными, переданными в него за кулисами, вместе с sessionToken, который, в свою очередь, устанавливается снова, идентично, при загрузке следующей страницы. Пользователь остается включенным, если в то же время cookie имеет «loggedin = true», и время истечения срока действия не прошло.
• Сессии истекают после настраиваемого времени. Истечение срока действия происходит при следующем нажатии на элемент навигации по истечении срока действия. Я считаю, что это просто сравнивая последний раз, когда токен сеанса был записан в бэкэнд, но, возможно, используется файл cookie - я еще не нашел этого. Когда сеансы заканчиваются, значение «loggedin» в cookie перебрасывается, и пользователь перенаправляется на страницу входа в систему.

Я не специалист по безопасности и не видел этот дизайн раньше. Мне было бы интересно узнать, какие подводные камни и риски, если таковые имеются, вы можете увидеть в нем. (Я, у меня плохое чувство, но хотел бы получить более твердый ввод.)

Если это стандартный способ в каком-то уголке сети, я бы тоже хотел услышать об этом.

Answer 1

Ian, в своем ответе, уже указал, что зависимость значений cookie для указания аутентичного характера пользователя является плохим. Я сосредоточусь на том, как управляется файл cookie сеанса.

Сессионные файлы cookie/токены должны быть уникальными, и они не предназначены для разглашения другим пользователям. Использование HTTPS гарантирует, что их нельзя обнюхивать на проводе в вашем приложении.Но возможно ли угадать значения токена сеанса? Если это так, у вас есть проблема; современное приложение полагается на безопасную структуру для генерации файлов cookie сеанса/токенов с использованием хорошего PRNG. Если ваше приложение не обладает аналогичным уровнем случайности, тогда предположите, что токен сеанса можно легко вывести, что приводит к тому, что пользователи могут обманывать других пользователей.

Более того, использование шифрования в определенных частях токена сеанса является интересным. Является ли ключ дешифрования для этих частей безопасным образом управляемым? Другими словами, является ли ключевой жесткий код или он является единственным ключом для каждой установки или генерируется случайным образом с коротким сроком службы? Если ключ можно угадать, вывести или скомпрометировать каким-либо образом, то у вас будет более или менее та же проблема.

Использование шифрования для сеансового ключа также может придать ему чувствительность к атаке оскорбления, но я не уверен в этом. Более подробная информация поможет.

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

Наконец, необходимо проверить наличие жесткой конфигурации для продолжительности сеанса и/или продолжительности скольжения по истечении срока действия токена сеанса. В противном случае вполне возможно, чтобы скомпрометированный сеанс был как можно дольше жив, иногда требуя «физического» выселения злоумышленника из-за характера определенных систем.

PS: Также проверьте алгоритм хеширования, используемый для паролей; использование соли хорошо. MD5 нарушается для всех практических целей.

Последствия использования механизма

пользовательского управления сеансом На первый взгляд, использование сессионных токенов без использования куки, как представляется, без каких-либо существенных проблем, но один имеет тенденцию терять несколько функций безопасности, доступны на большинстве платформ - флагов файлов cookie. Флаг secure и HttpOnly cookie уменьшает риск того, что cookie будет обнюхиваться на проводе (при отправке клиентом на сервер), а также гарантирует, что клиентский код не имеет доступа к токену, который впоследствии может быть скомпрометирован атака XSS. Таким образом, использование cookie сеанса лучше, чем использование пользовательского токена сеанса (с небольшим или отсутствием экспертной оценки, выполненной в ходе реализации).

Answer 2

Печенье, очевидно, может быть манипулировать, так что-нибудь подобное «LoggedIn = истина» для проверки подлинности поднимает флаг, если он не используется исключительно в качестве способа, который приводит к дальнейшей проверки подлинности против SessionID и т.д.

Upon выхода из системы в cookie следует удалить, а не «loggedin = false».

Безопасность, похоже, зависит от содержимого sessionToken. Убедитесь, что значение не может быть выделено и повторно собрано с измененной важной информацией (идентификатор пользователя, флаг прав администратора и т. Д.), Только с помощью декодирования/повторного кодирования base64.

Навигация полностью через представление формы не является стандартным методом сессии. Я предлагаю переместить sessionToken в файл cookie.