Что хранить в сеансе?

Question

Я знаю обо всех проблемах с фиксацией сессии и угоном. У меня очень простой вопрос: я хочу создать систему аутентификации на PHP. Для этого после входа в систему я бы просто сохранил идентификатор пользователя в сеансе.

Но: я видел, что некоторые люди делают странные вещи, например, генерируют GUID для каждого пользователя и сеанса и сохраняют его вместо просто идентификатора пользователя в сеансе. Зачем?

Контент сеанса не может быть получен клиентом - или это возможно?

Answer 1

Ты прав. Клиент просто видит случайно сгенерированный токен идентификатора сеанса. Есть способы, которыми этот токен может быть использован не по назначению (взломан и т. Д.), Но наличие GUID сверху ничего не добавляет. Напротив, такие параметры, как session.cookie_httponly (JavaScript не видит cookie сеанса) session.cookie_secure (cookie может передаваться только по HTTPS) защищают от определенных сценариев атаки.

Answer 2

Короткий ответ: $ _SESSION безопасен , и вам не нужно беспокоиться о том, что его содержимое просочится пользователю или злоумышленнику.

Содержимое сеанса не обычно быть доступным для пользователя.Вы должны быть в состоянии сохранить первичный ключ пользователя, и все будет в порядке.Существуют случаи, когда сеанс может быть пропущен, в обычной системе linux папка сеанса находится в / tmp, однако это может быть изменено в вашем php.ini на корневой веб-каталог (/ var / www / tmp) и затем может быть доступно,Единственный другой способ - это если пользователь может получить доступ к суперглобальному $ _SESSION, перехватив вызов eval () или напечатав переменную нормально.

Если вы работаете на общем хосте ииспользуя старую версию PHP и / или ваш сервер неверно настроен, для другого пользователя в этой системе может быть возможность прочитать или даже изменить файл сеанса, хранящийся в / tmp /.Я не знаю ни одного приложения, которое бы учитывало эту атаку.Если это проблема, вы можете сохранить информацию в таблице session в базе данных.

Answer 3

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

• Сохранение IP-адреса пользователя - если вам нужно принудительно изменить сеанс в зависимости от местоположения (иногда это будет делать геоИП)
• Хранение строки заголовка HTTP_USER_AGENT пользователя. Может обеспечить некоторую защиту от угона, если угонщик использует другой браузер.

В Википедии есть замечательная статья о мерах противодействия взлому сессии .

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

Answer 4

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

Это просто добавление еще одной вещи, которую угадывает угонщик. Тем не менее, это может быть ложное чувство безопасности, так как он мало защищает сеанс, если используется сниффинг, поскольку новый файл cookie отправляется вместе с файлом cookie сеанса php. Кроме того, идентификаторы сессий очень трудно угадать как есть (как я уверен, вы знаете, просто не помещайте их в URL, а скорее в cookie).

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