Система входа в систему PHP
Я создаю систему входа в систему для веб-приложения с использованием PHP. Мой вопрос в том, безопасно ли хранить информацию о входе пользователя только в текущем сеансе? Например, если пользователь по имени Джон успешно заходит на мой сайт, могу ли я просто сохранить $_SESSION['Имя пользователя'] = 'John' и $_SESSION['LoggedIn'] = 1, а затем проверить, что $_SESSION['LoggedIn'] равно 1 на каждой странице, чтобы убедиться, что пользователь действительно вошел в систему? Или есть лучший способ сделать это? Я не знаю о каких-либо проблемах в этом это может вызвать у меня головокружение, но я хотел убедиться, что не оставляю на своем сайте большой дыры, которая могла бы вызвать проблемы в будущем.
Кроме того, я сохраняю хэш md5 пароля пользователя + соль в базе данных, а не их фактический строковый пароль, так что об этом стоит беспокоиться меньше.
Дайте мне знать, если вам нужна дополнительная информация или если это неясно. Спасибо!
6 answers
Это совершенно разумный подход. Ваши посетители никогда не смогут редактировать данные сеанса на вашем сервере (если только сам сервер не является небезопасным, и в этом случае все честно), поэтому значение LoggedIn=1 в сеансе совершенно безопасно.
Однако имейте в виду риск того, что один посетитель захватит сеанс другого (путем кражи ключа сеанса). Один из способов защиты от этого - также сохранить IP-адрес посетителя (от $_SERVER['REMOTE_ADDR']) в сеансе, а затем в последующих запросах подтвердите, что он не изменился.
Существует ряд рисков, которые следует учитывать:
- Захват сеанса: это когда кто-то крадет файл cookie пользователя и притворяется им. Некоторые предложат IP-фильтрацию, чтобы противостоять этому, но это может иметь неприятные побочные эффекты. Люди используют веб-сайты с мобильных устройств или на ноутбуках, которые используются на работе, дома и в точках доступа Wi-Fi, и есть другие случаи, когда IP-адреса могут меняться. Поэтому мой совет - делайте это только для очень чувствительных веб-сайтов (например, онлайн банковское дело);
- Ваш сайт скомпрометирован: в этом случае пользователь в любом случае будет иметь доступ к вашей базе данных, поэтому нет дополнительного риска при хранении аутентификационной информации в сеансе. Они могут так же легко изменить свою личность, отправив инструкции по обновлению в вашу базу данных;
- Совместно размещенный сайт скомпрометирован: если вы используете общий хостинг, совершенно не связанный сайт может подвергнуть вас риску (с этой схемой или без нее), потому что все сайты работают на один и тот же экземпляр Apache и, таким образом, могут получать доступ к файлам друг друга (хотя может быть трудно определить, какому сайту они принадлежат). Поэтому, если сайт, о котором вы никогда не слышали, взломан, это может повлиять на ваш сайт;
- Совместно размещенный сайт является вредоносным: аналогично (3), за исключением того, что угроза является внутренней, но в остальном аналогична.
Поэтому я бы сказал, что это нормально (с учетом (2)), но просто имейте в виду риски. Следуйте, как минимум, этим рекомендациям:
- Никогда не храните незашифрованные пароли;
- Используйте сильный алгоритм хеширования (предпочтительный SHA1 или, по крайней мере, MD5);
- Убедитесь, что срок действия файлов cookie аутентификации истекает в какой-то момент. Как долго, зависит от вашего сайта. Это может быть неделя или две, или час или два бездействия, или и то, и другое.
Рассмотрите SHA1 или еще более сильный хэш вместо MD5. Но ты его солишь, это хорошо.
Возвращаясь к вашему вопросу: да, все в порядке. Тем не менее, примите меры, чтобы убедиться, что сеансы не будут захвачены. В Википедии на самом деле есть довольно хорошая статья об этом.
В большинстве систем, которые я написал, я включил логику для проверки того, что удаленный IP-адрес не изменился. Вы также можете сохранить это в сеансе, так как переменные сеанса не передаются пользователю (только идентификатор сеанса). Если вы действительно хотите проявить творческий подход, вы можете добавить другие проверки - агент пользователя, а что нет.
Вы также должны учитывать атаки сеанса. Проверьте рефереров. Если у вас катастрофическая операция, назовем ее СООБЩЕНИЕМ об удалении учетной записи, я могу написать отправку формы плюс javascript, чтобы нажать DeleteMyAccount в сообщении на форуме на несвязанном сайте, рассчитывая, что этот сеанс будет присутствовать в информации пользователя.
Звучит нормально; возможно, вам захочется подумать о том, чтобы установить время истечения срока действия (поэтому, если кто-то уйдет и оставит браузер открытым, он не будет в слишком большой опасности).
В целом, вы определенно на правильном пути. Я бы рекомендовал вам использовать идентификаторы для ваших пользователей в сеансе, а не имя пользователя, поскольку идентификаторы являются лучшей уникальной ссылкой внутри вашего кода.
Кроме того, md5 больше не считается достаточно надежным для хэширования паролей: он слишком быстр для хэширования, и вы не хотите, чтобы это проверялось, чтобы злоумышленнику нужно было запускать снова и снова (в то время как реальный пользователь должен сделать это только один раз). Я хотел бы найти ссылку, но ведущую мудрость края заключается в том, чтобы выполнять множество раундов алгоритма хэширования переднего края, такого как sha512.
Вы можете использовать COOKIE вместо переменной СЕАНСА. вы можете установить файл COOKIE, выполнив следующие действия
Setcookie('идентификатор', $переменная, время()+8*60*60);
Вы должны быть осведомлены о внедрении SQL. Когда вы вставляете или обновляете свою базу данных, к которой относится пользовательское текстовое поле, пожалуйста, помните о внедрении SQL. Вставьте/обновите свои значения с помощью функции htmlentities().