Jump to content

Recommended Posts

Anyone could help or giude how to secure this script by storing session into database?

 

login.php

 

<?php
    //Start session
    session_start();
    
    //Include database connection details
    require_once('config.php');
    
    //Get ip
    function get_client_ip() {
     $ipaddress = '';
     if ($_SERVER['HTTP_CLIENT_IP'])
         $ipaddress = $_SERVER['HTTP_CLIENT_IP'];
     else if($_SERVER['HTTP_X_FORWARDED_FOR'])
         $ipaddress = $_SERVER['HTTP_X_FORWARDED_FOR'];
     else if($_SERVER['HTTP_X_FORWARDED'])
         $ipaddress = $_SERVER['HTTP_X_FORWARDED'];
     else if($_SERVER['HTTP_FORWARDED_FOR'])
         $ipaddress = $_SERVER['HTTP_FORWARDED_FOR'];
     else if($_SERVER['HTTP_FORWARDED'])
         $ipaddress = $_SERVER['HTTP_FORWARDED'];
     else if($_SERVER['REMOTE_ADDR'])
         $ipaddress = $_SERVER['REMOTE_ADDR'];
     else
         $ipaddress = 'UNKNOWN';

     return $ipaddress;
}
    
    //Array to store validation errors
    $errmsg_arr = array();
    
    //Validation error flag
    $errflag = false;
    
    //Function to sanitize values received from the form. Prevents SQL injection
    function clean($str) {
        $str = @trim($str);
        if(get_magic_quotes_gpc()) {
            $str = stripslashes($str);
        }
        return mysql_real_escape_string($str);
    }
    
    //Sanitize the POST values
    $login = clean($_POST['login']);
    $password = clean($_POST['password']);
    $ip = get_client_ip();
    
    //Input Validations
    if($login == '') {
        $errmsg_arr[] = 'Login ID missing';
        $errflag = true;
    }
    if($password == '') {
        $errmsg_arr[] = 'Password missing';
        $errflag = true;
    }
/*    if($login != '' || $password != '') {
    if($login !='admin' && $ip !=''.$log_ip.''){
        $errmsg_arr[] = 'Your IP <b>'.$ip.'</b> is not recognized...';
        $errflag = true;
        }
    }    
*/    
    //If there are input validations, redirect back to the login form
    if($errflag) {
        $_SESSION['ERRMSG_ARR'] = $errmsg_arr;
        session_write_close();
        //header("location: index.php");
        echo ('<meta http-equiv="refresh" content="0;url=index.php">');
        exit();
    }
    
    //Create query
    $qry="SELECT * FROM members WHERE login='$login' AND passwd='".$_POST['password']."'";
    $result=mysql_query($qry);
    
    //Check whether the query was successful or not
    if($result) {
        if(mysql_num_rows($result) == 1) {
            //Login Successful
            session_regenerate_id();
            $member = mysql_fetch_assoc($result);
            $_SESSION['SESS_MEMBER_ID'] = $member['member_id'];
            $_SESSION['SESS_LOGIN_NAME'] = $member['login'];
            $_SESSION['SESS_PASS'] = $member['passwd'];
            session_write_close();
            //header("location: member-index.php");
            echo ('<meta http-equiv="refresh" content="0;url=member-index.php">');
            exit();
        }else {
            //Login failed
            //header("location: login-failed.php");
            echo ('<meta http-equiv="refresh" content="0;url=login-failed.php">');
            exit();
        }
    }else {
        die("Query failed");
    }
?>

 

auth.php (included on top of all php pages

 

 

<?php
    //Start session
    session_start();
    
    //Check whether the session variable SESS_MEMBER_ID is present or not
    if(!isset($_SESSION['SESS_MEMBER_ID']) || (trim($_SESSION['SESS_MEMBER_ID']) == '')) {
        //header("location: access-denied.php");
        echo ('<meta http-equiv="refresh" content="0;url=access-denied.php">');
        exit();
    }
?>

That wikiHow article is, again, a good example of how not to do it.

 

Why do you want to store the sessions in the database? Why do you think this makes you more secure?

 

I strongly recommend that you do not do this. Handling sessions is much harder than you may think. For example, you now have to worry about concurrency issues: Process A and process B both read a variable of the same session, say amount with a current value of 0. Process A increases amount by 100, process B increases it by 200. Common sense tells us the result should be 300. But it's actually 200, because B has overwritten the update of A. How do you prevent this?

 

The standard PHP sessions already take care of those ugly little details. But if you implement your own session handler (or steal it from some crap website), then you're suddenly confronted with all kinds of problems you probably haven't even thought about yet. So, just stick to the standard.

 

There are much worse security issues, anyway:

  • Why on earth do you store the user password in the session? The passwords are sensitive data. You must protect them, not throw them around in some temporary files. What is that supposed to do, anyway?
  • You store the passwords as plaintext? Seriously? Again: The passwords are sensitive data. You need to hash them with a strong algorithm like bcrypt.
  • Your code is wide open to SQL injections through the password parameter, because you drop $_POST['password'] right into your query.
  • Your whole escaping strategy is rather questionable. What is your clean() function supposed to do? “Clean” for what?
  • Do you really still have magic quotes turned on? I thought that stuff died somewhere in the 90s.
  • The mysql_* functions you're using are obsolete since more than 10 years and will be removed in one of the next PHP releases. Nowadays, we use PDO. This will also help you solve your injection vulnerabilities, because the new database extensions support parameterized queries.
  • In my opinion, IP checks are bullshit. But that's another story, I guess.

So before you do the fine-tuning of your security, please fix the gaping holes.

storing session data in a database is actually less secure than using the default file session save handler, because with the database, the security is now dependent on how strong your database credentials are, how well access to the database server has been limited, and on how secure ALL of your code that has access to that same database is.

 

what sort of problem are you having that you are trying to solve?

the problem am as of now facing is within few mins of login the script automatically logs out if no activity. yes i got is solved it by session.gc_maxlifetime = 21600 by default it is 1440 but this is a headache can i not do something with the above code to make session last for longer?

storing session data in a database is actually less secure than using the default file session save handler, because with the database, the security is now dependent on how strong your database credentials are, how well access to the database server has been limited, and on how secure ALL of your code that has access to that same database is.

 

what sort of problem are you having that you are trying to solve?

That wikiHow article is, again, a good example of how not to do it.

 

Why do you want to store the sessions in the database? Why do you think this makes you more secure?

 

I strongly recommend that you do not do this. Handling sessions is much harder than you may think. For example, you now have to worry about concurrency issues: Process A and process B both read a variable of the same session, say amount with a current value of 0. Process A increases amount by 100, process B increases it by 200. Common sense tells us the result should be 300. But it's actually 200, because B has overwritten the update of A. How do you prevent this?

 

The standard PHP sessions already take care of those ugly little details. But if you implement your own session handler (or steal it from some crap website), then you're suddenly confronted with all kinds of problems you probably haven't even thought about yet. So, just stick to the standard.

 

There are much worse security issues, anyway:

  • Why on earth do you store the user password in the session? The passwords are sensitive data. You must protect them, not throw them around in some temporary files. What is that supposed to do, anyway?
  • You store the passwords as plaintext? Seriously? Again: The passwords are sensitive data. You need to hash them with a strong algorithm like bcrypt.
  • Your code is wide open to SQL injections through the password parameter, because you drop $_POST['password'] right into your query.
  • Your whole escaping strategy is rather questionable. What is your clean() function supposed to do? “Clean” for what?
  • Do you really still have magic quotes turned on? I thought that stuff died somewhere in the 90s.
  • The mysql_* functions you're using are obsolete since more than 10 years and will be removed in one of the next PHP releases. Nowadays, we use PDO. This will also help you solve your injection vulnerabilities, because the new database extensions support parameterized queries.
  • In my opinion, IP checks are bullshit. But that's another story, I guess.

So before you do the fine-tuning of your security, please fix the gaping holes.

i get your point. :) thanks

Well, maybe you should go ahead and learn a little about it then?

 

There are plenty of ressources - and it's very well worth it.

 

http://code.tutsplus.com/tutorials/object-oriented-php-for-beginners--net-12762

thanks ues i definitely should do a little more study for sure

the problem am as of now facing is within few mins of login the script automatically logs out if no activity.

 

Well, then you should have asked for that rather than taking a detour in the hopes that it will somehow lead to the solution.

 

The first thing you should do is set an application-specific save path for the sessions. If the sessions are stored in some generic folder like /tmp, then you never know which process is deleting the files based on which criteria.

 

Then you need to check if the settings are working correctly. If you stick to a lifetime of 1440 seconds, when exactly do the sessions get cleaned up? Before 24 minutes? Exactly after 24 minutes?

Well, then you should have asked for that rather than taking a detour in the hopes that it will somehow lead to the solution.

 

The first thing you should do is set an application-specific save path for the sessions. If the sessions are stored in some generic folder like /tmp, then you never know which process is deleting the files based on which criteria.

 

Then you need to check if the settings are working correctly. If you stick to a lifetime of 1440 seconds, when exactly do the sessions get cleaned up? Before 24 minutes? Exactly after 24 minutes?

well session gets cleaned up way before 24mins sometimes even if idle for 3mins, how you show me how exactly i save session to different folder?

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.