Thanks for your replies. I have updated my PHP session code.
I have a (HTTPS)-login.php which remains HTTPS ie once user logged in goes to account dashboard. Now the problem is say the user whilst logged on to the dashboard clicks on the (HTTP)-about-us.php page the session is not transmitted over HTTP as I have session.cookie_secure=1, thats fine user appears logged out. However when the user goes back to dashboard page he is logged out on HTTPS as well?
I believe I am missing something which is causing this problem. Here is my code:
This is PHP header file require()ed to start session ie on login.php page:
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();}
This is PHP header file require()ed on every page to check if session initiated already:
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();}
Also if any use this is the code to turn HTTPS of on non-sensitive pages such as about-us.php
if ($_SERVER['SERVER_PORT']!=80)
{
$url = "http://". $_SERVER['SERVER_NAME'] . ":80".$_SERVER['REQUEST_URI'];
header("Location: $url");
}
Thanks again for any help guys, daza166
If you use ini_set('session.cookie_secure',1);
, the cookie with the session-id will only be transfered to the server if the connection is encrypted. So if you force the user to access about-us.php via an unsecure http-connection, your script won't receive the cookie and he will appear as logedout user on the page. You won't be able to access any session-variables.
However, neither the cookie on the client nor the session data on the server is deleted. So, if the user visits an encrypted page of your site later (within the lifetime of the session and the cookie), the still existing cookie with the session-id is transfered and he won't have to login again. In short, going from HTTPS to HTTP and back again won't log out the user. If you don't need to check the user's login-status on an unencrypted page, setting cookie_secure is a good idea.
To your other questions: In my opinion, checking the user agent does not significantly increase the level of security, because a hacker who is able to retrieve someone's session-id won't have many problems retrieving also his user-agent-string. Checking the id makes sense, but can cause problems if the users ip changes often due to reconnects or changing proxies.
It looks like you're asking a few different questions here, but to address this:
I was thinking is there any reason really to check user agent/IP etc as although it will lessen the chances of hijack it is simply comparing $_SESSION==$_SESSION ie (www.domain.com/login.php?hacker=no)
If you're asking why people compare session variables to what is being submitted, the answer is because the variables stored in $_SESSION
were defined at the beginning of the session, i.e. when the user logged in, presumably before the hijacking took place. (The hijacker can only hijack an existing session, and that session may have started without the hijacker having been involved.) Because of that, if we regularly compare the user agent string or IP address provided with the page request to the one we have stored from the beginning of our session, we may be able to detect a hijacking (assuming the hijacker has a different user agent string/IP address).
I don't know the answer to your HTTPS question.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With