PHP Lang
  1. PHP Lang
  3. Обновляет ли идентификатор сеанса после успешного входа в систему, чтобы предотвратить фиксацию сеанса?
Intereting Posts
Как стать гуру OpenCart? Не задана статическая переменная unset ()? PHP: как кодировать бесконечности или числа NaN для JSON? Заполнение раскрывающегося списка PHP из базы данных MySQL HTML-панель прогресса PHP PHP Определите, где была вызвана функция с PHP CakePHP Pagination с условиями на has_many Преобразование индексированного массива в обычный или простой массив php json_encode не приводит к реальной строке объекта / make массиву в реальном объекте / превращает php-массив в json Правильная реализация виртуальных функций в PHP? Google OAuth2 – isAccessTokenExpired () всегда верно запуск showdown.js serveride для преобразования Markdown в HTML (в PHP) Что такое параметризованный запрос? предотвращение подделки подпроса в URL-адресе Чтение данных из fsockopen с использованием fgets / fread hangs

Обновляет ли идентификатор сеанса после успешного входа в систему, чтобы предотвратить фиксацию сеанса?

В настоящее время я читаю руководство , и я немного смущен этим:

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

<?php $_SESSION['logged_in'] = FALSE; if (check_login()) { session_regenerate_id(); $_SESSION['logged_in'] = TRUE; } ?>

Если я это правильно понимаю, мне нужно только создать session_regenerate_id() прежде чем назначить значение, например logged_in = true или user_id = id а затем я сделал защиту от фиксации сеанса?

Этого достаточно? Что еще я могу сделать?

Solutions Collecting From Web of "Обновляет ли идентификатор сеанса после успешного входа в систему, чтобы предотвратить фиксацию сеанса?"

На самом деле наиболее распространенным сценарием с фиксацией сеанса является то, что злоумышленник разместит ссылку, например, на вашей домашней странице или странице входа, установив идентификатор сеанса на url (как переменную GET) и дождаться, когда некоторые пользователи войдут в систему. Так как злоумышленник знает идентификатор сеанса этих пользователей, и поскольку этот идентификатор сеанса может быть установлен в URL-адресе, злоумышленник может пересмотреть ссылку на страницу профиля / панели мониторинга зарегистрированного пользователя и выдать себя за этого пользователя.

Таким образом, для предотвращения таких видов атак регенерация идентификатора сеанса является достаточной, так как злоумышленник остается с неаутентифицированным сеансом. Дополнительный шаг, который вы можете предпринять, – не принимать идентификаторы сеанса в URL-адресе. Для этого вам необходимо установить (либо в php.ini, если у вас есть доступ к этому файлу на сервере или через ini_set):

  1. session.use_only_cookies должен быть установлен в TRUE (использовать только файлы cookie для идентификатора сеанса php и не передавать его по URL-адресу)
  2. session.use_trans_sid должен быть установлен в FALSE (идентификаторы сеансов никогда не должны передаваться по URL-адресу, если файлы cookie отключены)

Таким образом, злоумышленник даже не может установить идентификатор сеанса даже для сеанса без проверки подлинности.

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

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

Вот почему вы должны разрешать только идентификаторы сеансов через файлы cookie (см. Session.use_cookies_only ). Поскольку обычно злоумышленник не может перезаписывать файлы cookie жертвы (кроме других атак, таких как XSS или принудительное форматирование файлов cookie ).

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

Фиксация сеанса работает, устанавливая идентификатор сеанса жертвы на некоторый идентификатор, который знает злоумышленник. Затем злоумышленник ждет, когда пользователь войдет в систему. Если идентификатор сеанса не изменяется, на данный момент злоумышленник имеет доступ к учетной записи пользователя (у него есть идентификатор сеанса). Если идентификатор сеанса изменяется, атака неэффективна.