Web Session или Sessionless

Question

Я думаю о создании таблицы «сеанса», которая содержит случайный #, идентификатор пользователя, дату / время, который заполняется при входе пользователя в систему, и случайный #, используемый на каждой отображаемой странице, чтобы однозначно идентифицировать человека. Каждый раз, когда пользователь отображает страницу, запись будет обновляться с использованием самой последней активности даты / времени, если за последние x часов не было никаких действий, чем я планирую принудительно выполнить повторную регистрацию. Пара вопросов:

• Должен ли я включить IP (меня не интересуют мультисессии, но я подумал об этом для дополнительной безопасности)
• делает это лучше и безопаснее, чем стандартный подход PHP-сессии (куки и т. Д.)
• я должен использовать этот метод, а также php-сессию (cookie), чтобы сопоставить их, чтобы убедиться, что это правильный человек (cookie, включая IP и т. Д .??)

Есть ли лучший подход или стандартная схема безопасности, которая существует (и я не знаю о ней)?

Answer 1

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

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

Answer 2

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

Answer 3

Почему бы просто не использовать сеанс PHP по умолчанию и хранить его данные в базе данных?
Существует несколько функций, позволяющих переопределить действия PHP при доступе или обновлении сеанса.

Эта статья объясняет это.

Answer 4

Ответ Оба!

Суть: Вы должны никогда слепо принимать файлы cookie или сеансы для проверки пользователей, которые легко похищаются XSS и могут использоваться злоумышленником, отличным от источника.

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

Я выбрал метод checkin-checkout для состояния сеанса пользователя. В котором уникальный идентификатор создается при загрузке страницы, а переменная сеанса хранит этот уникальный идентификатор. Этот уникальный идентификатор также сохраняется для идентификатора пользователя в базе данных вместе с IP-адресом и изменениями IP-адреса. (Я также сохранил другие биты информации, которые были проверены)

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

Сценарий проверяет уникальный идентификатор на основе значения сеанса и IP-адреса в базе данных. Как только совпадение будет сделано, измените уникальный идентификатор и обновите базу данных. Если IP-адрес был изменен в течение x секунд, сделайте что-нибудь для этого пользователя (Принудительно новый вход в систему), если уникальные идентификаторы не совпадают, сделайте что-нибудь еще (например, выйдите из системы, предупредите и т. Д.), Если последнее действие было x секунд назад, сделайте что-нибудь для этого пользователя.

Итак, Войти-> Создать сеанс / Проверка пользователя-> Следующая страница-> Проверить сеанс с уникальным идентификатором базы данных + Проверить пользователя-> Создать новый идентификатор сеанса-> Обновить последнего пользователя / уникальный идентификатор пользователя

В конце концов, он может дать вам более полное представление о том, откуда ваши пользователи получают доступ к своим учетным записям и как часто из каждой точки EG: работа х 3, дом х 5, мобильный х 1, а также позволяет защитить ваши пользователи от краж аккаунта. EG: Немецкий пользователь неожиданно входит в систему из Таиланда или США. Сообщите им об изменениях и отправьте запрос на подтверждение изменений на их электронную почту.

Answer 5

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

Answer 6

Зачем вам нужно использовать базу данных для отслеживания сеансов. Вы не думаете, что это накладные расходы? Я бы посоветовал вам продолжить сеансы PHP.

Answer 7

1. Используйте куки для заполнения сессии.
2. Используйте сеанс для обычного использования.
3. Обязательно сохраняйте случайную строку в дБ за сеанс.
4. Сохраняйте IP-адреса в db только для вашей собственной информации, если вам нужно временно запретить IP, но не используйте их, как будто они безошибочны.

Answer 8

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

Сохраняйте значения в сессиях, так как это меньше затрат, и вы можете установить время окончания сессии, когда захотите. Это решает весь «последний раз, когда они вошли в систему» ​​без лишних вычислений.

Вся цель сеанса - хранить значения, относящиеся к этому человеку, на этом компьютере, и это именно то, что вы ищете. Дублирование, которое кажется излишним.

Answer 9

1. IP может быть полезен, но в случае, если кто-то имеет динамический IP, он не рекомендуется для чего-то большего, чем контрольная точка.

2. Я бы предложил использовать подход сеанса, потому что обычно это 20-минутный тайм-аут, если он не изменен администратором сервера.

Answer 10

Точка 1 - зависит от того, есть ли у людей статические IP-адреса

Пункт 2. Хранение сеансов в базе данных потребуется для решения проблем балансировки нагрузки и избыточности. Это также зависит от того, насколько занята ваша заявка.

Пункт 3 - Один или другой должен быть адекватным.