Безопасно ли хранить id пользователя из бд в сессии?
Предыстория
Чуть больше года назад, был задан вопрос по поведению кэша на сайте и единственный ответ затронул момент хранения пароля в куки. Всё это время, тема хэширования, аутентификации, авторизации не давала мне покоя.
Ссылка на вопрос: Некорректное поведение кэша сайта?
К чему было решено прийти
Хэширование пароля через password_hash и проверка через password_verify
Проблематика
Сейчас после авторизации, пользователь аутентифицируется по связке
Логину + паролю + ключу аутентификации из куки
К слову, вся эта солянка перехэширована в MD5
Тем самым было принято решение перейти на систему сессий
Вопрос
Стоит ли использовать ID пользователя из базы данных при указании сессии или есть какие-то определённые стандарты на этот счёт?
$_SESSION['user_id'] = $user['id'];
В приоритете использовать длительные сессии, которые не слетают после 24-х минут или при закрытии браузера пользователем
На что ориентируюсь
Крупные компании по типу: ВК, Яндекса, Таймвеба и т.п.
Через консоль просмотрел у них сессию и заметил что они значительно длиннее стандартной PHPSESSID
Статьи с которыми ознакомился:
https://habr.com/ru/articles/665602/
https://habr.com/ru/articles/728072/
https://habr.com/ru/companies/avanpost/articles/480576/
Дополнительно:
Вы не путайте ID сессии ( то, что прилетает на клиента) с тем, что в сессии хранится (и остаётся на сервере. Уязвимость может быть только в случае, если злоумышленник доберётся до хранилища сессий ( в самом просто случае это каталог с файлами) и сможет читать оттуда.
Ответы:
В сессии и так хранится ID. Иначе, как приложение узнает, с кем имеет дело?
- ID из базы же явный
Если есть пользователь 100
Значит до него минимум 99 пользователей
И если подменить user_id, если такое конечно возможно, не откроет ли это доступа к его личным данным?
Возможно стоит использовать случайно сгенерированный хэш и идентифицировать пользователя по нему? - Хотя изучив эту тему:
Можно ли подменить сессию?Полагаю что такое не возможно и можно спокойно использовать user_id
- EngineGP,
ID пользователя не является каким-то секретом. Для чего его скрывать? Вы можете сделать автоинкремент от любого числа. - Можете вместо автоинкремента использовать UUID, если паранойя.
- Sanes, лучше уж hashid
- DevMan, чем лучше?
- Sanes, обратимый и короче.
Если вы сами не вываливаете содержимое сессии в ответы сервера на пользовательские запросы, то хранение в ней чего угодно абсолютно безопасно - данные хранятся на стороне сервера и пользователям не видны. Так что смело сохраняйте в ней все, что вам нужно в ней сохранить, сессии для этого и придуманы.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Хранение id пользователя из базы данных в сессии может быть безопасным, если определенные меры безопасности соблюдаются. Однако, есть несколько важных моментов, которые следует учитывать:
1. Никогда не храните пароли или другую чувствительную информацию в сессии. Используйте только идентификатор пользователя для определения его сеанса.
2. Убедитесь, что ваше приложение защищено от атак межсайтовой подделки запроса (CSRF). Для этого рекомендуется генерировать уникальный CSRF-токен для каждой сессии и проверять его при выполнении запросов.
3. Проверяйте права доступа пользователя перед предоставлением ему доступа к конфиденциальным данным. Убедитесь, что пользователь имеет право просматривать или изменять информацию, хранящуюся в базе данных.
4. Регулярно проверяйте и обновляйте ваше приложение на наличие уязвимостей безопасности. Это поможет предотвратить возможные атаки и утечки данных.
Пример безопасного хранения id пользователя в сессии на языке PHP:
session_start(); // Получаем id пользователя из базы данных $user_id = $row['id']; // Записываем id пользователя в сессию $_SESSION['user_id'] = $user_id;
Следуя этим рекомендациям, вы можете обеспечить безопасное хранение id пользователя из базы данных в сессии. Важно помнить, что безопасность всегда должна быть приоритетом при разработке веб-приложений.