Является ли это безопасным использованием переменных сеанса?

Question

Я использовал $ _SESSION ['name'] для обработки данных со страницы на страницу. В основном я использовал его для того, чтобы пользователь регистрировался между страницами. На каждой странице я проверяю, является ли значение $ _SESSION [logged_in '] истинным или нет. Если значение true, заставьте войти в систему. В противном случае сделайте что-нибудь еще.

Это, как я обрабатывать мои сессии - основной образец:

<?php 

session_start(); 

if($_SESSION['logged_in']) 
{ 
    //show control panel list 
} 
else 
{ 
    //show login box. Once user logs in. Once user logs in, 
    //fetch userID, username, etc from database. Also set 
    //$_SESSION['logged_in'] = true. 
} 

?> 

Где-то между кодами я сделать следующее:

SELECT * FROM User WHERE userID = $_SESSION['userID']; 

Я не уверен, что если $ _SESSION [ 'идентификатор пользователя' ] будут доступны пользователям или нет. Если это доступно, страница будет угрожать, потому что пользователь может вручную изменить идентификатор пользователя и получить доступ к другой учетной записи, которую он желает.

Я не в безопасности. Пожалуйста посоветуй! Что я могу сделать?

Примечание: я стараюсь сделать код максимально простым. На данный момент никакой уловки не задействован.

Answer 1

Это очень хорошо, вот несколько советов для управления сеансами:

1. не принимают идентификаторы сеанса из переменных GET/POST: идентификаторы сессий в URL (строка запроса, GET переменные) или POST-переменные не рекомендуется, так как это упрощает эту атаку. Легко создавать ссылки на формы, которые задают переменные GET/POST.

2. Восстановить SID по каждому запросу: В PHP используется session_regenerate_id(). Каждый раз, когда уровень доступа пользователя изменяется, необходимо восстановить идентификатор сеанса. Это означает, что, хотя злоумышленник может обмануть пользователя в принятии известного SID, SID будет недействительным, когда злоумышленник попытается повторно использовать SID.

Answer 2

$ _SESSION является одной из серверных Super Globals. Он недоступен пользователям или передан с вашего сервера каким-либо образом.

Answer 3

Да, это в значительной степени правильная идея.

Вот несколько ресурсов, которые могут помочь, как с безопасностью понимания сеанса и безопасного программирования в целом:

http://phpsec.org/projects/guide/4.html http://phpsec.org/projects/guide/

Answer 4

Ваш код уязвим для фиксации сеанса и атак на захват сеанса. См. http://phpsec.org/projects/guide/4.html для получения дополнительной информации.

По мере того, как вы создаете более крупные, более привлекательные приложения, вы также захотите быть осторожными, как вы обрабатываете регистрацию пользователя и обрабатываете другие связанные с сеансом аспекты, такие как эскалация привилегий. Безопасное управление сеансами и входами - это сложный зверь.

Реализация безопасной аутентификации затруднена. Если вы не делаете это как академическое упражнение, я настоятельно рекомендую использовать библиотеку, предоставленную вашей инфраструктурой, если вам посчастливилось иметь хороший.

Вы также хотите, чтобы рассмотреть такие вещи, как:

• Не разрешайте идентификатор сеанса будет принудительно. [фиксация сеанса]
• При изменении прав доступа или учетных данных (например, поскольку пользователь сейчас вошел или вышел из системы), то немедленно аннулирует сеанс и запускает новый.
• Предоставьте функцию выхода из системы и убедитесь, что она недействительна для сеанса при выходе из системы.
• Установить cookie сеанса на HttpOnly - желательно, HTTPS и alo установить cookie только для защиты.
• Рассмотрите возможность ограничения срока действия сеанса, чтобы включить проверку другой информации, которая помогает сопоставить пользователя, например. Агент пользователя. [session hijacking]
• Всегда заканчивайте сеансы после неиспользования и не выполняйте «сохранить меня вошедшим в систему», повторно подключив пользователя к своей старой http-сессии.
• Убедитесь, что все связанные с сеансом данные уничтожены, когда сеанс недействителен, независимо от того, где он хранится. Новый пользователь, входящий, может просто получить назначенный идентификатор сеанса, который использовался ранее. Этот новый сеанс не должен иметь никакого доступа к данным сеанса, которые были установлены ранее против этого идентификатора сеанса.