Контрольные вопросы при входе в систему с помощью SESSIONS (PHPSESSID) или COOKIES, если то же самое .. или нет?

Question

У меня есть несколько вопросов о SESSIONS и COOKIES, я прочитал в inte rnet, и все люди рекомендуют использовать SESSIONS (для безопасности), но .. Не то же самое, что сохранить логин ID в одном сеансе (phpsessid), который сохраняется в одном приготовлении ie?

Я тестировал это:

Я скопировал свой идентификатор PHPSESSID (cook ie) из моей учетной записи с веб-сайта (в chrome) и вставил PHPSESSID (cook ie) в другом браузере (в Opera) с VPN, и я могу получить доступ в этой учетной записи.

Какая здесь безопасность? если кто-нибудь может угадать или угнать моего повара ie PHPSESSID ID такой же, если я использую Cook ie для сохранения идентификатора входа, или нет?

Мой вопрос ... Не более безопасно использовать безопасный cook ie ID, как в wordpress, шифрование ID и проверка в БД IP и USER_AGENT?

Теперь я использую это: я создаю случайный идентификатор и сохраняю в одном поваре ie (когда пользователь входит в систему является успехом) И проверьте, существует ли этот идентификатор в БД, проверьте, равны ли IP (сохраненный в БД) и USER_AGENT (сохраненный в БД). если нет, войдите в систему в другой раз

Кто-нибудь может мне немного помочь? Спасибо за прочтение.

Answer 1

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

Слабым звеном в сеансах является то, что HTTP является протоколом без сохранения состояния, поэтому клиент должен идентифицировать себя при каждом запросе (в отличие от того, что происходит в другие сетевые протоколы, такие как FTP, S SH или SMTP). Более ранние реализации передавали идентификатор сеанса в самом URL-адресе. Позже было улучшено использование только файлов cookie, и файлы cookie можно настроить так, чтобы они ограничивались зашифрованными соединениями. Но да, если что-то перехватит ваш HTTP-трафик c и узнает ваш идентификатор сеанса, он может легко выдать себя за вас, потому что большинство сайтов не заботятся о проведении дальнейших проверок. Однако именно поэтому в настоящее время HTTPS рекомендуется.

Answer 2

Вы должны спросить себя: «Насколько легко угадать случайно сгенерированный случайный идентификатор?».

Если ваш ответ на этот вопрос «очень простой», вам будет труднее угадать его. Используйте UUID или другую форму надежно случайного идентификатора.

Если вы ответили «довольно сложно», вам не следует об этом беспокоиться. Единственный предлагаемый вами вектор атаки - это возможность угадать случайно сгенерированный идентификатор.

Вы можете узнать больше о «угадывании PHPSESSID» здесь .

В общем случае нет необходимости проверять IP-адреса пользователя (в качестве примечания, вы открываете себя для всего, что описано в GDPR, делая это) или их User-Agent, так как обе вещи могут измениться в течение времени существования сеанса.