#php #session
#php #сеанс
Вопрос:
Спасибо за ваши ответы. Я обновил свой сессионный код PHP.
У меня есть (HTTPS)-login.php который остается HTTPS, т.е. после входа пользователя в систему переходит на панель управления учетной записью. Теперь проблема в том, что пользователь, вошедший в панель мониторинга, нажимает на (HTTP)-about-us.php страница сеанс не передается по HTTP, так как у меня есть session.cookie_secure = 1, это нормально, пользователь, похоже, вышел из системы. Однако, когда пользователь возвращается на страницу панели мониторинга, он также выходит из системы по HTTPS?
Я полагаю, что мне чего-то не хватает, что вызывает эту проблему. Вот мой код:
Это файл заголовка PHP, требующий () редактирования для запуска сеанса ie на login.php страница:
session_start();
session_regenerate_id(true); /*avoid session fixation attempt*/
/*Create and check how long session has been started (over 5 mins) regenerate id - avoid session hijack*/
if(!isset($_SESSION['CREATED']))
{
$_SESSION['CREATED'] = time();/*time created session, ie from login/contact advertiser/email_confirm only ways for new session to start*/
}
elseif(time() - $_SESSION['CREATED'] > 300)
{
/*session started more than 5 mins(300 secs) ago*/
session_regenerate_id(true); /*change session ID for the current session and invalidate old session ID*/
$_SESSION['CREATED'] = time(); /*update creation time*/
}
/*Check if user is logged in*/
if(!isset($_SESSION['loggedin']))
{
$_SESSION['loggedin']=1;/*used to track if user is logged in on pages*/
}
/*if return false browser supports standard ob_start();*/
if(ob_start("ob_gzhandler")){ob_start();}
Это файл заголовка PHP, который require () редактируется на каждой странице, чтобы проверить, был ли сеанс уже инициирован:
session_start();
$session_errors=0;/* if>0 user not logged in*/
/*check if session is already initiated*/
if(isset($_SESSION['CREATED']))
{
if(time() - $_SESSION['CREATED'] > 300)
{
/*session started more than 5 mins(300 secs) ago*/
session_regenerate_id(true); /*change session ID for the current session and invalidate old session ID*/
$_SESSION['CREATED'] = time(); /*update creation time*/
}
}
elseif(!isset($_SESSION['CREATED'])){$session_errors ;}/*user not logged in*/
/*Check if user is logged in*/
if(!isset($_SESSION['loggedin'])){$session_errors ;}/*user not logged in*/
if(ob_start("ob_gzhandler")){ob_start();}
Также, если таковые имеются, используйте этот код для включения HTTPS на нечувствительных страницах, таких как about-us.php
if ($_SERVER['SERVER_PORT']!=80)
{
$url = "http://". $_SERVER['SERVER_NAME'] . ":80".$_SERVER['REQUEST_URI'];
header("Location: $url");
}
Еще раз спасибо за любую помощь, ребята, daza166
Ответ №1:
При использовании ini_set('session.cookie_secure',1); cookie с идентификатором сеанса будет передан на сервер только в том случае, если соединение зашифровано. Итак, если вы принудительно предоставляете пользователю доступ about-us.php через незащищенное http-соединение ваш скрипт не получит cookie, и он появится на странице как пользователь, вышедший из системы. Вы не сможете получить доступ ни к каким переменным сеанса.
Однако ни файл cookie на клиенте, ни данные сеанса на сервере не удаляются. Таким образом, если пользователь посещает зашифрованную страницу вашего сайта позже (в течение срока действия сеанса и файла cookie), все еще существующий файл cookie с идентификатором сеанса передается, и ему не придется входить в систему снова. Короче говоря, переход с HTTPS на HTTP и обратно не приведет к выходу пользователя из системы. Если вам не нужно проверять статус входа пользователя на незашифрованной странице, установка cookie_secure — хорошая идея.
К другим вашим вопросам: На мой взгляд, проверка пользовательского агента существенно не повышает уровень безопасности, потому что у хакера, который может получить чей-либо идентификатор сеанса, не возникнет особых проблем с получением также его строки пользовательского агента. Проверка идентификатора имеет смысл, но может вызвать проблемы, если ip пользователей часто меняется из-за переподключений или смены прокси.
Комментарии:
1. Итак, на about-us.php идентификатор сеанса не будет виден, означает ли это, что я не могу получить доступ к любым переменным $ _SESSION при возврате к http-соединению? Также, какие проверки, по вашему мнению, мне нужны (если таковые имеются) для безопасности сеанса или будет достаточно только HTTPS и проверки $ _SESSION [‘loggedin’]? Наконец, нужно ли мне проверять переменные $ _SESSION, т.Е. $ _SESSION [’email’] имеет формат электронной почты, если используется в каком-либо действии, и безопасно ли указывать userid или advert_ref в $ _SESSION var, если пользователь заполняет серию форм, а не _POST их как скрытые поля?
2. ^ -Я включил ini_sets перед моим session_start (), но когда я перехожу с HTTPS на HTTP и обратно на HTTPS, мой $ _SESSION больше не существует, т.Е. пользователь больше не вошел в систему?
3. Чтобы ответить на ваш последний вопрос о безопасном использовании переменных сеанса: посетитель не сможет изменять ничего, доступ к чему осуществляется через $ _SESSION (он остается на сервере), но только данные, к которым осуществляется доступ через $ _COOKIE. Таким образом, если вы подтвердите адрес электронной почты, а затем сохраните его в сеансе, вам не придется проверять его снова на другой странице, которая считывает его из сеанса. Таким образом, вы могли бы использовать данные хранилища сеанса в ряде форм. Однако это может привести к неожиданному результату, если пользователь использует кнопку «Назад», поскольку уже введенные данные остаются в сеансе.
Ответ №2:
Похоже, что вы задаете здесь несколько разных вопросов, но для решения этого:
Я думал, есть ли какая-либо причина действительно проверять пользовательский агент / IP и т.д., Поскольку, хотя это уменьшит шансы на захват, это просто сравнение $ _SESSION == $ _SESSION ie (www.domain.com/login.php?hacker=no )
Если вы спрашиваете, почему люди сравнивают переменные сеанса с тем, что передается, ответ заключается в том, что переменные, хранящиеся в $_SESSION , были определены в начале сеанса, то есть при входе пользователя в систему, предположительно до того, как произошел захват. (Злоумышленник может перехватить только существующий сеанс, и этот сеанс, возможно, начался без участия злоумышленника.) Из-за этого, если мы регулярно сравниваем строку пользовательского агента или IP-адрес, предоставленные при запросе страницы, с тем, который мы сохранили с начала нашего сеанса, мы можем быть в состоянии обнаружить перехват (при условии, что у взломщика другая строка пользовательского агента / IP-адрес).
Я не знаю ответа на ваш вопрос HTTPS.