Безопасность сеанса

Question

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

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

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

Большое спасибо заранее.

Answer 1

Это кажется относительно безопасным, но есть несколько способов это можно обойти:

• Если ключ сеанса украден, хэш может быть украден тоже. Пока законный клиент ничего не делает, угонщик может просто взять на себя ответственность и поддерживать согласованность ключей/хешей/данных. Вы не увидите ничего, пока законный клиент не проснется ... если вообще.

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

Answer 2

Звучит отлично.

Одна вещь, которую вы, возможно, захотите добавить в свой алгоритм аутентификации, - это IP-адрес, из которого пользователь приходит.

Это может быть не так хорошо для текущей аутентификации пользователя, но в случае взлома сеанса другой IP-адрес будет представлять собой огромный флаг, но вы можете использовать эту информацию для добавления в правило таблиц IP для блокировки потенциальных злонамеренных пользователей.

Еще одна мысль - отслеживать URL ссылки. Что касается злонамеренного поведения, то, видя, откуда кто-то приходит из-за какой-либо консистенции, может пролить свет в программе (если есть).

Answer 3

Я не понимаю, какова точка хэша данных сеанса. Какую проблему он решает?

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

Кроме того, если вы скопируете старую сессию, я не знаю, что вы достигли этим?

Просто простой идентификатор сессии и:

• изменить его при входе в систему, чтобы избежать фиксации сессии и
• запирать его на IP, чтобы избежать злоумышленник берет на себя управление через sidejacking.

Чтобы злоумышленник не видел данные, вам необходимо использовать SSL.

Answer 4

Вы не можете рассчитывать на уникальный или не изменяющийся IP-адрес. Корпоративные брандмауэры обычно объединяются или даже случайно меняют IP-адреса посредством NAT-трансляции. Это может сделать систему более надежной, но она играет хаос на схемах аутентификации сервера, которые пытаются использовать один и тот же IP-адрес.

В последние несколько лет существует еще одна проблема - системы намного более мобильны, чем раньше. Я обычно «спящий» свои ноутбуки вместо того, чтобы закрыть их, но это означает, что я прихожу из разных по IP-адресам дома, в работе, в Starbucks и т. Д. Это может привести к отключению серверов с тайм-аутами сеанса до 15-30 минут - мне просто нужно время, чтобы добраться из моего офиса до обеда и т. д.