Что сохранить на сессии?
Я знаю обо всех проблемах с фиксацией сессии и угоном. Мой вопрос является действительно основным: Я хочу создать систему аутентификации с PHP. Для этого, после входа в систему, я просто сохранил бы идентификатор пользователя на сессии.
Но: я видел, что некоторые люди делают странные вещи как генерация GUID для каждого пользователя и сессии и хранения это вместо просто идентификатора пользователя на сессии. Почему?
Содержание сессии не может быть получено клиентом - или может оно?
4 ответа
Короткий ответ: $ _SESSION безопасен , и вам не нужно беспокоиться о том, что его содержимое будет передано пользователю или злоумышленнику. .
Содержимое сеанса не обычно доступно пользователю. Вы должны иметь возможность хранить первичный ключ пользователя, и все будет в порядке.Бывают случаи, когда может произойти утечка сеанса, в обычной системе Linux папка сеанса находится в / tmp, однако это может быть изменено в вашем php.ini на корневой веб-сайт (/ var / www / tmp), а затем может быть доступным . Единственный другой способ - это если пользователь может получить доступ к суперглобалу $ _SESSION путем перехвата вызова eval () или обычной печати переменной.
Если вы работаете на общем хосте и используете старую версию PHP и / или ваш сервер неправильно настроен, другой пользователь в этой системе может прочитать или даже изменить файл сеанса, хранящийся в / tmp /. Я не знаю ни одного приложения, которое учитывает эту атаку. Если это проблема, вы можете сохранить информацию в таблице сеанса в базе данных.
Вы правы. Клиент просто видит случайно сгенерированный токен идентификатора сеанса. Есть способы использования этого токена не по назначению (взлом и т. Д.), Но наличие GUID наверху ничего не добавляет. Напротив, такие параметры, как session.cookie_httponly (JavaScript не может видеть cookie сеанса) session.cookie_secure (Cookie может передаваться только по HTTPS), защищают от определенных сценариев атак.
Иногда, для дополнительной безопасности, разработчики могут назначать длинную строку для пользователя сеанс, чтобы еще больше усложнить захват. Установив файл cookie с этой новой строкой во время создания сеанса, приложение может проверять правильность строки при последующих запросах, чтобы лучше убедиться, что это человек, который на самом деле вошел в систему.
Это просто добавляет еще одну вещь для подражателя-угонщика придется угадывать. Однако это может быть ложным чувством безопасности, поскольку оно мало что делает для защиты сеанса, если задействовано обнюхивание, потому что новый файл cookie отправляется вместе с файлом cookie сеанса php. Кроме того, идентификаторы сеанса очень сложно угадать как таковые (как я уверен, вы знаете, просто не помещайте его в URL-адрес, а, скорее, в файл cookie).
Информация о сеансе хранится на жестком диске, поэтому клиенты не могут получить ее без вмешательства приложения.
Я никогда не видел, чтобы идентификаторы GUID использовались для сеансов, но есть несколько дополнительных методов, которые я видел, которые добавляют немного большей безопасности.
- Сохранение IP-адреса пользователя - если вам нужно принудительно изменить сеанс в зависимости от местоположения (иногда это делает материал geoIP)
- Сохранение строки заголовка HTTP_USER_AGENT пользователя. Может обеспечить некоторую защиту от угона, если угонщик использует другой браузер.
На самом деле в Википедии есть отличная статья о мерах противодействия перехвату сеанса .
При этом я могу представить, что любой, кто хранит GUID как часть сеанса для использования в безопасности сеанса, может не найти лучшего решения (например, регенерации сеанса). Я вижу другие варианты использования сохраняемого GUID (возможно, это часть случайного генератора для игры), но не для использования с безопасностью сеанса.