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

Question

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

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

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

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

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

Answer 1

Кукисами, очевидно, можно манипулировать, поэтому что-либо вроде «loggedin = true» для аутентификации поднимает флаг, если только оно не используется строго как метод, который приводит к дальнейшим проверкам аутентификации с помощью sessionid и т. Д.

При выходе из системыфайл cookie должен быть удален, но не должен иметь значение «loggedin = false».

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

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

Answer 2

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

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

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

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

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

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

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

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

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