Web Analytics Made Easy -
StatCounter Trying to password protect a web page using sessions...not working - CodingForum

Announcement

Collapse
No announcement yet.

Trying to password protect a web page using sessions...not working

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Trying to password protect a web page using sessions...not working

    Hello again, experts,

    This should be simple project.

    We have two web pages, one is called register.php and the other registered.php.

    There is a log in page.

    Once user is authenticated, then if that user has not registered, s/h will be redirected to register.php.

    If the user is authenticated and has already registered, user is redirected to registered.php to review his/her registration details.

    I think these work fine.

    But I am having one major issue.

    If a user attempts to go to any of the two pages, register.php and registered.php, without logging in, the user is supposed to get a message that "you must log in first to see this page"

    So far, one, the message doesn't display.

    Second and more importantly, you can easily type the url to go to any of the pages and you get in, again, with no message.

    I think the issue has to do with the parameters I am passing to the pages before user is redirected.

    Question is can someone please help me with a better way of solving this issue?

    Here is the code and thanks a lot in advance.

    Code:
    <?php
    	session_start();
      error_reporting(E_ERROR | E_WARNING | E_PARSE);
    
     // Connect to SQL Server database
     include("Connect.php");
    // this function is used to sanitize code against sql injection attack.
    function ms_escape_string($data) {
            if ( !isset($data) or empty($data) ) return '';
            if ( is_numeric($data) ) return $data;
    
            $non_displayables = array(
                '/%0[0-8bcef]/',            // url encoded 00-08, 11, 12, 14, 15
                '/%1[0-9a-f]/',             // url encoded 16-31
                '/[\x00-\x08]/',            // 00-08
                '/\x0b/',                   // 11
                '/\x0c/',                   // 12
                '/[\x0e-\x1f]/'             // 14-31
            );
            foreach ( $non_displayables as $regex )
                $data = preg_replace( $regex, '', $data );
            $data = str_replace("'", "''", $data );
            return $data;
        }
    
     $user = trim($_POST['user']);
     $pass = trim($_POST['pass']);
    
         // hash to sanitize the input further
    
      //	$tsql = md5($pass);
    
       //Lets check to ensure user has proper credentials.
       $tsql = "SELECT u.empl_first, u.username, u.empl_first +' '+ empl_last as fullname FROM users u WHERE u.USERNAME = ? and u.PASSWORD =? ";
    	//echo $strSQL;
    	$params = array('$user', '$pass');
        $result = sqlsrv_query( $con, $tsql, $params, array( "Scrollable" => 'static' ));
    
        $row_count = sqlsrv_num_rows($result);
        //echo $row_count;
    
        if ($row_count == 0){
           header('location:login.php?msg=1');
           exit;
    
    }
    
    
    //If we get this user, then user is properly authenticated. So, let's take user to appropriate page based on whether or not user has
    //submitted his or her responses.
       $tSQL = "SELECT u.empl_first, u.username FROM users u inner join tblTA t on u.Employee_Id = t.Employee_ID WHERE USERNAME = ?
    	and PASSWORD = ? ";
    	//echo $tSQL;
        $params = array($user, $pass);
    	$sqll = sqlsrv_query($con, $tSQL, $params);
    
    if ($objResult = sqlsrv_fetch_array($sqll, SQLSRV_FETCH_ASSOC)) {
        $firstname = $objResult["empl_first"];
         $username = $objResult["username"];
     	$_SESSION["firstname"] = $objResult["empl_first"];
         $_SESSION['loggedin'] = true;
         $_SESSION['username'] = $username;
    
    	header('location:donetba.php?user=' . urlencode($firstname));
      }
      else
          $firstname = $objResult["empl_first"];
           $username = $objResult["username"];
       	$_SESSION["firstname"] = $objResult["empl_first"];
           $_SESSION['loggedin'] = true;
         $_SESSION['username'] = $username;
        header("location:tba.php?user='".ms_escape_string($user)."'&pass='".ms_escape_string($pass)."' ");
    
    sqlsrv_close($con);
    
    ?>
    Then on register.php, I have this:

    Code:
    <?php
    session_start();
    if (!isset($_SESSION['loggedin']) || $_SESSION['loggedin'] != true)
    {
        echo "Please log in first to see this page";
    }
    Last edited by simflex; Sep 20, 2016, 12:06 PM.

  • #2
    Second and more importantly, you can easily type the url to go to any of the pages and you get in, again, with no message.
    first thing to do is checking what's in the session data.

    note: sqlsrv supports prepared statements. no need to use an untested function when you can have 100% protection.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

    Comment


    • #3
      Thank you very much for your response.

      I have removed those functions and decided to try session instead.

      Like this:

      Code:
      if ($objResult = sqlsrv_fetch_array($sqll, SQLSRV_FETCH_ASSOC)) {
          $firstname = $objResult["empl_first"];
           $username = $objResult["username"];
           $password = $objResult["password"];
       	$_SESSION["firstname"] = $objResult["empl_first"];
           $_SESSION['loggedin'] = true;
           $_SESSION['username'] = $username;
           $_SESSION['password'] = $password;
      	header('location:registered.php');
        }
        else
          $firstname = $objResult["empl_first"];
           $username = $objResult["username"];
           $password = $objResult["password"];
       	$_SESSION["firstname"] = $objResult["empl_first"];
           $_SESSION['loggedin'] = true;
           $_SESSION['username'] = $username;
           $_SESSION['password'] = $password;
          header("location:register.php");
      Then on the register.php page for instance, I am doing this:

      Code:
       $strSQL = "SELECT u.empl_first, u.empl_first +' '+ empl_last as fullname, e.Department, e.UnitName, e.empnum FROM users u inner join EmployeeData e on u.Employee_Id = e.EmpNum WHERE USERNAME = '".$_SESSION['username']."'
      	and PASSWORD = '".$_SESSION['password']."' ";
      Problem is you are right, no value in those sessions and I am reasonably confident is because of the parametized query.

      Am I using that incorrectly?

      I know you mentioned prepared statement but if I stay with what I have now, given I have gone far with it, I can start to play with prepared statement in my next task.

      I am trying so hard to transition from .net to php but I find a lot of the stuff I am able to do relatively easily with .net like this session stuff, I am struggling with php and I told php is easier than .net.

      Comment


      • #4
        I am trying so hard to transition from .net to php but I find a lot of the stuff I am able to do relatively easily with .net like this session stuff, I am struggling with php and I told php is easier than .net.
        PHP sessions ain't complicated either ... you only need to make sure you don't have output before starting a session. (=> error_reporting())

        whether the following checks succeed is in most cases a logic issue.

        you might also want to look into PDO - it can be used with MSSQL as well and has a straightforward API that is easy to understand.
        The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
        André Behrens, NY Times Software Developer

        Comment


        • #5
          PHP sessions ain't complicated either ... you only need to make sure you don't have output before starting a session. (=> error_reporting())

          As you can see from the code I posted and above and snippet below, I started session first before error -reporting code.

          Code:
          <?php
          	session_start();
            error_reporting(E_ERROR | E_WARNING | E_PARSE);

          Comment


          • #6
            for development you should enable all error levels (i.e. error_reporting(-1)).
            The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
            André Behrens, NY Times Software Developer

            Comment


            • #7
              First thing that I would suggest is instead of having two separate user-callable files for register or registered, you have one that you can include from any page you want to restrict. In practice I use the "one index.php to rule them all" approach to site-building, but that takes a bit more work.

              This single user_login.php would start the session, regenerate the ID, and test if the user is logged in. If not, call the login form and die() so they cannot continue to the rest of your page. If they are trying to, log them in, add the "logged in" message to a $messages type array to be shown in the page template, if login fails spit them back at the login form. If they either get logged in or if they are already logged in, then you proceed.

              I would also suggest that the login form be a separate file from that so it is only included when neeeded, but that it not be user-callable or be allowed to spit out anything if called directly -- and that means wrapping anything it does in functions or objects.

              ... and hash yer bloody PW's, and it would help if you used CONSISTENT use of case in your table structures and queries. Upper-case in field names can get mangled by certain backup and restore methods, so the accepted practice is lowercase on field names and all caps for SQL commands.

              One thing that might simplify your life, is instead of storing the user name and a boolean "logged in" as your only real method of tracking the user, you use the user record's ID# (which should be your primary key) -- it allows you to leverage the relational part of relational databases for better access, integers are faster than strings, and you could use a value like -1 to indicate "guest" if you want the ability to let people browse on some pages as guest but still provide the login link if they aren't logged in. To that end a define, like say "DIE_IF_GUEST" could be used to determine if a guest should be booted or not.

              ... and best of all it would axe that header redirect nonsense and passing the password back client-side which is something to be avoided. It's bad enough it's passed to you once without giving an extra chance for MITM to nab it... PARTICULARLY as $_GET. There's a reason it's considered bad practice to EVER do a login or password handling as method="get", and that's what your tba.php? is doing there opening a way bigger hole than that nonsensical ms_escape_string garbage would ever even in theory plug.

              On the subject of that ms_escape_string thing, even if you wanted to reject things like username or password on what characters are used, that's validation not sanitation -- if they try to feed you invalid characters you spit the form back in their face, NOT blindly "clean" it and press on as if nothing was wrong. Dormlich has it right on the rest of that -- you're using sqlsrv and prepared queries, lose that "ms_escape_string" nonsense as that type of regex rubbish serves ZERO legitimate purpose once you migrate away from blindly dumping variables into your query strings. It handles all that FOR YOU. If you're worried about XSS, STOP passing the UN/PW on the URI, STOP screwing around with redirects, and htmlspecialchars any time you're going to output a value in your markup.

              You use prepare/execute, you htmlspecialchars when outputting user created values to the markup, there are no code injection vulnerabilities -- PERIOD!

              If I have time later I might gut out of my own codebase how I go about it and neuter it down a bit (mines significantly more complex) as an example here. Right now I'm still chugging morning coffee and shaking off the cobwebs.
              Walk the dark path, sleep with angels, call the past for help.
              https://cutcodedown.com
              https://medium.com/@deathshadow

              Comment


              • #8
                Thank you guys for all the useful inputs.

                Comment

                Working...
                X