Почему и когда следует использовать функцию session_regenerate_id() в php? Должен ли я всегда использовать его после использования session_start() ? Я прочитал, что я должен использовать его для предотвращения фиксации сеанса, это единственная причина?
session_regenerate_id() ? Как говорит имя функции, это функция, которая заменит текущий идентификатор сеанса на новый и сохранит текущую информацию сеанса.
Это в основном помогает предотвратить атаки с фиксацией сеанса. Атаки фиксации сеансов – это то, где злоумышленник пытается использовать уязвимость в системе для фиксации (установки) идентификатора сеанса (SID) другого пользователя. Поступая таким образом, они получат полный доступ в качестве исходного пользователя и смогут выполнять задачи, которые в противном случае требовали бы аутентификации.
Чтобы предотвратить такие атаки, назначьте пользователю новый идентификатор сеанса, используя session_regenerate_id() когда он успешно session_regenerate_id() (или для каждого X-запроса). Теперь только у него есть идентификатор сеанса, и ваш старый (фиксированный) идентификатор сеанса больше не действителен.
session_regenerate_id() ? Как указывает Symbecean в комментариях ниже, идентификатор сеанса должен быть изменен при любом переходе в состоянии аутентификации и только при переходе на аутентификацию.
Дальнейшее чтение:
Вы должны использовать session_regenerate_id() , чтобы остановить захват сеанса и фиксацию сеанса .
Из этого ответа Security.SE :
Захват сеанса означает кражу файла cookie сеанса. Это проще всего выполнить при совместном использовании локальной сети с другими компьютерами. Например, в Starbucks. Пример … пользователь с сеансом Y просматривает веб-сайт Джеймса в Starbucks. Я слушаю их сетевой трафик, потягивая свой латте. Я беру пользователя с кукисами сессии Y для веб-сайта Джеймса и устанавливаю мой браузер, чтобы использовать их. Теперь, когда я получаю доступ к сайту Джеймса, сайту Джеймса.
На этой веб-странице :
Session Fixation – это метод атаки, который заставляет идентификатор сеанса пользователя иметь явное значение. В зависимости от функциональности целевого веб-сайта можно использовать ряд методов для «исправления» значения идентификатора сеанса. Эти методы варьируются от эксплойтов Cross-Site Scripting до перетаскивания веб-сайта с ранее выполненными HTTP-запросами. После того, как идентификатор сеанса пользователя будет исправлен, злоумышленник будет ожидать, что этот пользователь войдет в систему. Как только пользователь делает это, злоумышленник использует предопределенное значение идентификатора сеанса, чтобы принять тот же идентификатор онлайн.
Когда использовать
Когда пользователь редактирует или обновляет некоторые важные входы (смена паролей, учетных данных, забытых паролей и т. Д.), Которые могут нарушить безопасность сайта или политику конфиденциальности.
Смотрите также:
Руководство по безопасности PHP: сеансы
Фиксация сеанса (Nice read)
session_regenerate_id ? Вы должны использовать его для предотвращения фиксации сеанса .
session_regenerate_id ? Всякий раз, когда изменяется состояние аутентификации, это происходит главным образом при входе в систему и выходе из системы.
Боб сидит на общедоступном компьютере и просматривая stackoverflow.com, он открывает там новую сессию. Идентификатор сеанса сохраняется в httpOnly cookie (с флагом httpOnly для предотвращения доступа через javascript). Представим, что Stack Overflow всегда поддерживал HTTPS, а также secure флаг, установленный для файла cookie.
Как мы можем украсть сеанс сейчас?
Боб записывает идентификатор сеанса. Он покидает компьютер, не закрывая браузер. Теперь Алиса приходит к этому компьютеру и видит, что Stack Overflow уже загружен. Сейчас она входит в систему.
Теперь мы находимся на том этапе, где вы должны использовать session_regenerate_id . Если вы не создадите новый идентификатор сеанса здесь во время входа в систему, Боб может использовать предыдущий сеанс, который он записал для доступа к сессии Алисы, и теперь будет зарегистрирован как Алиса.
Вы можете использовать его для лучшей безопасности.
Таким образом вы создаете идентификатор сеанса для одноразового использования.
Допустим, что ваш идентификатор сеанса пользователя = 3
Некоторые хакеры взломали ваш клиент и получили их session_id. Таким образом, хакер может использовать этот файл cookie для использования своей сессии.
Если у вас есть код вроде
session_start(); session_regenerate_id();
вы можете менять свою сессию каждый раз, когда используете свой веб-сайт.
Теперь хакер получает sessionid = 3
но вы изменили сеанс после того, как он использовал это, чтобы ваш
у пользователя есть sessionid = 4 // auth
У хакера есть session = 3 // null
Но есть небольшая точка, позволяющая сказать, что вы используете метод регенерации и ваш клиент просто заходите на сайт и закрываете браузер или неактивны. У вашего клиента есть sessionid = 4, и если хакер получает файлы cookie в этой части, у них будет такой же сеанс.
Как объяснено выше, таким образом вы можете защитить своего клиента от обнюхивания данных одним способом, но все же его не устранит эту проблему навсегда.
Но это будет очень безопасно, если вы используете SSL enc.
Извините за плохой английский.
Простой вариант:
// User visits a webshop $shopcart = new Cart();
Запускается сеанс, и запись делается в базе данных. Товарная корзина пользователя идентифицируется его идентификатором сеанса.
// User orders items $shopcart->add('123', 20); $shopcart->add('124', 18); $shopcart->add('127', 5);
Для каждого добавленного продукта запись делается в моей таблице магазина. Также идентифицируется идентификатором сеанса.
// User saves cart in order to use it later $shopcart->save();
Пользователь решил спасти свою тележку. Теперь он привязан к его идентификатору пользователя.
// Regenerate session id for user to be able to make a new cart session_regenerate_id();
Идентификатор sesssion восстанавливается, и теперь пользователь может начать создание другого магазина.
Я думаю, что проблема заражения сеансами была довольно хорошо освещена.
Чтобы ответить на вопрос «Когда я должен использовать это?» часть, важно отступить и рассмотреть, что ваше приложение делает с сеансом. Или, другими словами, это ключевой вопрос безопасности, который вам нужно ответить
Если кто-то завладеет этой сессией, что они получат?
Если все, что вы делаете, это отслеживать анонимные данные (пользователь приходит на сайт, и вы используете его для отслеживания их посещений), тогда нет причин для восстановления сеанса. Угонщик не получил бы ничего полезного, захватив этот сеанс.
Однако многие сайты предлагают логины. Вход меняет много вещей. Я могу получить доступ к своему профилю. Я могу изменить настройки. Так угонщик может захотеть получить доступ к моей учетной записи, особенно если обычные и административные пользователи используют сеансы для управления логином. Поэтому, когда люди приходят на мой сайт и регистрируются, я восстанавливаю сессию. Он добавляет дополнительный уровень безопасности, который мой недавно зарегистрированный пользователь с меньшей вероятностью получит захват.
Каждый раз, когда мы добавляем критические данные в сеанс, вы должны рассмотреть возможность восстановления идентификатора сеанса. Если вам нужно закрепить приложение против фиксации, тогда может быть полезно случайное восстановление, но я НИКОГДА не обновлялся бы при каждом запросе. По умолчанию PHP хранит сеансы в файлах на локальном диске. Вы добавляете много дискового ввода-вывода для смягчения того, что является относительно небольшим вектором атаки. Если вы действительно нуждаетесь в большей безопасности, я бы отстаивал необходимость полного HTTPS над регенерацией на регулярной основе (HTTPS очень сильно фиксирует фиксацию).
session_regenerate_id (): невозможно восстановить идентификатор сеанса – сеанс неактивен
if(session_status() == PHP_SESSION_ACTIVE) { session_regenerate_id(); }