I wrote the log In/log Out scripts of my web page and when the user logs in I store in the $_SESSION variable the user agent. Now each time a page is loaded I check if the user is logged in or not and if it is logged in I check if the user agent has changed or is still the same to prevent hijacking. In case it has changed I call my logOut() function:

function logOut($conn) 
    $sql = "UPDATE Users SET logged='no' WHERE username='" . $_SESSION['username'] ."'";

    // Unset all session values 
    $_SESSION = array();

    // get session parameters 
    $params = session_get_cookie_params();

    // Delete the actual cookie. 
    setcookie(session_name(), '', time() - 42000, 

    // Destroy session 

Now the problem is that the right user can still navigate my website as logged in while I would like to have it logged out. What could be the problem?

To test my code I logged in using Mozilla Firefox and I copied the value of the cookie in Chrome and reloaded the home page and as expected I am unable to log in with Chrome but if I reload the page in Mozilla it is still logged in. If I remove the user agent check then I am able to access the page as logged in in Chrome so my code is half working.

  • 2
    First and foremost: Never write your own session handler.
    – rook
    Dec 14, 2014 at 16:01
  • I fear you're asking the wrong question in the wrong forum in the wrong way. Checking the user agent to prevent session hijacking is naive, because the UA can easily be forged and obtained. An attacker who is skilled enough to steal the secret session ID is certainly able to get the public(!) UA as well. So your whole approach is already questionable. Secondly, your code contains no UA check or context whatsoever. We cannot debug code which isn't there. And third, I'm not sure if Security.SE is the right platform for programming issues. As far as I'm aware, that's the domain of Stackoverflow.
    – Fleche
    Dec 14, 2014 at 19:48

4 Answers 4


Your scheme is problematic from a UX and Security standpoint.

Bad UX, If implemented properly a user who logs in on their phone will immediately be logged out on their computer, or whatever. There are several other problematic cases where users who shouldn't be logged out are logged out. That's not horrible, but depending on the use of your application is can be really annoying

Security - First, your code is vulnerable to SQL injection.

$sql = "UPDATE Users SET logged='no' WHERE username='" . $_SESSION['username'] ."'";

My username is USERNAME' or '1'='1

If this is allowed in your username policy, an attacker can force log off of all users (or whatever other SQL they want). Use parameterized queries or if you're stubborn, fix your password policy.

Finally UserAgent checks are probably not super effective. User Agent strings are not super unique. For example, if your website has 1million users get their session hijacked, the attacker will probably be using the same browser as a pretty large portion of them (without even trying to bypass your security solution).

To answer your actual question, session_unset() or session_destroy() will do what you want, but only after you call session_start().

  • When, at sign up, I store the username in the database I use parameterized sql queries and when I set $_SESSION['username'] I take the value stored in the database so I thought sql injection couldn't be a problem here, anyways I will use parameterized sql queries here as well. My website will use HTTPS but I was wondering what are other good ways to prevent hijacking, as you pointed out the user agent is quite simple to bypass. Dec 15, 2014 at 14:02
  • It sounds like you are vulnerable to SQLi then. If the username contains sql code, it will run if concatenated in like youre doing.
    – user11869
    Dec 15, 2014 at 14:14
  • If I understood you right, if some user uses 1=1 or some sql code as the username the database would be compromised, but I programmed the sign up php scrypt to store the username only if it contains alphanumeric characters and the only symbol allowed is the underscore otherwise it will show invalid username. I am doing it both client side and server side. Is it still vulnerable? Dec 15, 2014 at 18:10

Session hijacking is a serious threat, it has to handle by using a secure socket layer for advanced application which involves transactions or by using simple techniques like using cookies, session timeouts and regenerates id etc as explained above.
When the internet was born, HTTP communications were designed to be stateless; that is, a connection between two entities exists only for the brief period of time required for a request to be sent to the server, and the resulting response passed back to the client. Here are a few methods which hackers follow to hijack the session

  • Network Eavesdropping
  • Unwitting Exposure
  • Forwarding, Proxies, and Phishing
  • Reverse Proxies

Always recommend SSL Secure Sockets Layer
Use cookies also to following ini_set() directives at the start of your scripts, in order to override any global settings in php.ini:

ini_set( 'session.use_only_cookies', TRUE );                
ini_set( 'session.use_trans_sid', FALSE );

Use Session Timeouts and Session Regenerate ID

// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )         
 // if authenticated, generate a new random session ID

 // set session to authenticated
  $_SESSION['auth'] = TRUE;

 // redirect to make the new session ID live

 header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
// take some action

this is simple. first set the session cookie's HttpOnly use TLS ssl, meaning you have everything encrypted and modifications are detected set cookie.secure prevent any XSS, sql injection, or any other injection then you should generate new session at every login and invalidate old sessions

that should be all against session hijacking


best way is following some tutorial


for safely destroy


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .