Пока я читал о сеансах захвата статей, я узнал, что было бы неплохо зашифровать значение идентификатора сеанса, которое хранится в файле cookie.
Насколько мне известно, когда я запускаю сеанс, вызывая session_start() , PHP не шифрует значение идентификатора сеанса в cookie.
Как зашифровать значение идентификатора сеанса, а затем инициализировать сеанс с ним?
Шифрование не поможет. В любом случае, cookie сеанса – всего лишь волшебное число. Шифрование это просто означает, что есть другой магический номер для захвата. В зависимости от сценариев захвата, которые вы имеете в виду, есть и другие возможные смягчения. Например, вы можете ограничить сеансы одним IP-адресом. Это создает некоторые проблемы, например, люди, переключающиеся между беспроводными точками.
Более важно, чтобы ваши идентификаторы сеансов были случайными (т. Е. Кто-то не может использовать свой идентификатор сеанса, чтобы угадать другого человека), поскольку реальная опасность заключается в том, что кто-то получает доступ к идентификатору сеанса другого пользователя. Пока вы держите их по-настоящему случайными, нет никаких оснований для шифрования
Предполагая, что ваш cookie сеанса является GUID, нет смысла шифровать его. Он просто заменил бы одну псевдослучайную строку на другую.
К сожалению, шифрование идентификатора сеанса не приведет к значительному повышению безопасности, так как злоумышленник может просто использовать зашифрованную форму (которая является единственной видимой для них в любом случае).
Единственное, что это может помешать, – это трюк, в котором вы отправляете кому-то ссылку? PHPSESSID = foo в нем, что заставит PHP создать этот сеанс. Это можно предотвратить, используя шифрование и проверку, но вы должны полностью отключить передачу идентификатора сеанса в URL-адресе.
Всегда хорошая идея никогда не зависеть только от одного файла cookie или элемента для проверки ваших (зарегистрированных) пользователей (пользователей). Как уже упоминалось выше, неплохо также сохранить IP-адрес и проверить его. Хорошим дополнением будет сохранение USER_AGENT.
Готовьте, что если ваше приложение открыто, вы так же хорошо справляетесь с идентификатором сеанса, потому что хакер может легко определить, к чему вы проверяете.
Создайте этот сценарий, откройте его из веб-браузера, затем проверьте свои файлы cookie.
<?php session_start(); ?>
Вероятно, вы увидите что-то подобное
Site Cookie Value mysite.com PHPSESSID 6fktilab3hldc5277r94qh2204
PHP отлично справляется с созданием приятного уникального идентификатора. Нет смысла шифровать это.
Идентификатор сеанса относительно неочевиден, так что это не проблема.
Есть вещи, которые вы можете сделать, связанные с этим, чтобы противодействовать атакам:
Есть немало других вещей. Я всегда рекомендую изучить Rails Guide по этим вопросам – он предлагает очень доступное объяснение известных проблем и контрмер – все одинаково применимы к PHP-коду.
Имеет смысл шифровать данные cookie, когда вы используете файлы cookie для хранения конфиденциальной информации. что только сервер должен читать (расшифровывать).
Нет причин для шифрования идентификатора сеанса, поскольку хакер может использовать этот зашифрованный идентификатор сеанса для выдачи себя за жертву.