Вопрос безопасности Codeigniter / PHP

Я разрабатываю веб-приложение с помощью Codeigniter. Когда пользователь проходит аутентификацию с моего сайта, я в настоящее время храню свой «идентификатор пользователя» в своем cookie сеанса (на котором я включил шифрование). Некоторые из моих классов моделей используют значение в параметре user-identifier session / cookie для внесения изменений в свойства учетных записей пользователей.

Мое беспокойство заключается в том, что мне интересно, возможно ли кому-то взять действительный файл cookie-кода с идентификатором пользователя, который я установил, изменить значение идентификатора пользователя на значение другого пользователя и внести изменения в другой учетной записи пользователя. Были ли ошибки codeigniter / php, если кто-то попытался изменить свойство cookie сеанса?

Solutions Collecting From Web of "Вопрос безопасности Codeigniter / PHP"

Откройте файл /application/config/config.php, найдите «sess_use_database» и измените его на «ИСТИНА», если вы еще этого не сделали. Таким образом, все переменные сеанса будут храниться в таблице базы данных, а файл cookie сеанса будет содержать только строку идентификатора сеанса.

Для дополнительной безопасности вы также можете изменить «sess_match_ip» на TRUE. Таким образом, если кто-то украдет cookie вашего пользователя и попытается передать его как свой, сеанс будет уничтожен.

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

Мой ответ на самом деле не связан с CI, поэтому, пожалуйста, имейте это в виду.

Когда вы авторизуете пользователя «username1», что должно быть отправлено обратно клиенту, для целей auth должно быть хешем, который сервер коррелирует с этим пользователем. Вся связь между клиентом и сервером будет опираться на этот хеш.

Сервер будет генерировать уникальный хеш для каждого пользователя, и хэш должен иметь короткое время для жизни. Может ли кто-то захватить хэш и пройти как этот пользователь? Безусловно. Вот почему вы должны также проверить, чтобы агент и IP-адрес пользователя проверяли, соответствуют ли они хешу, чтобы предотвратить захват сеанса.

НИКОГДА НЕ ДЕЛАЙТЕ ЭТО:
Если замечены некоторые новые разработчики, которые хранят имя пользователя в cookie и полагаются на эту клиентскую переменную, чтобы обновлять свои базы данных. Никогда не делай этого. Никогда не доверяйте клиенту. Когда сервер получает хэш-файл клиента, он должен проверить, принадлежит ли он аутентифицированному пользователю и захватить user_id (переменную для обновления пользовательских данных) с сервера. НИКОГДА от клиента.

Я не уверен, что ваш «идентификатор пользователя» точно. Общее правило: не храните ничего в файле cookie сеанса, кроме идентификатора сеанса. Храните все остальное (например, идентификатор пользователя) на стороне сервера и извлекайте его с помощью идентификатора сеанса.

Если пользователь изменяет идентификатор сеанса (который является случайной строкой), начнется новый сеанс. Идея идентификатора сеанса заключается в том, что невозможно угадать идентификаторы других пользователей – вот почему это случайность и так долго.