0

I've got a website where the user can log in and when they do two session variables get set:

if (validate_password($password, $user_hash))
{
    $_SESSION['usrnam'] = $username;
    $_SESSION['uid'] = $user_id;
    $stmt -> close();
    $con -> close();
    dirto_homepage();
    exit();
}

Then i do checks to display elements on page:

if (isset($_SESSION['uid']) && isset($_SESSION['usrnam'])) {include ".....";}

and ... 

$auth_id = $con -> real_escape_string($_SESSION['uid']);
$message = $con -> real_escape_string($_POST['message']);
$stmt = $con -> prepare("UPDATE `db_table` SET `data` = ?, `date_mod` = ? WHERE `id` = ? AND `author_id` = ?")

Is this secure to do? - The uid is just the auto increment number of the users details in the database. Is there anything i can do to make user login checking more robust?

Crizly
  • 971
  • 1
  • 12
  • 33
  • Best practices / Security issues : http://codereview.stackexchange.com/ – Clément Malet Aug 19 '14 at 15:50
  • well you could also log the users ip, user agent etc, to protect against session hijacking. you could also save the password hash in session, and check it against the db to invalidate open sessions after a password change, but what you have is probably fine – Steve Aug 19 '14 at 15:50
  • You should NOT escape the string if you're using parametrized queries. The parameter binding already protects the data, if you add any escapes they'll be treated as literal data. – Barmar Aug 19 '14 at 15:52

2 Answers2

1

It's wrong to use real_escape_string if you're providing it as a bound parameter to a prepared statement. Bound parameters are treated literally, and the binding mechanism takes care of protecting the values, so you'll store the escape characters into the database, which you don't want. Escaping is only necarry if you're substituting the value into the SQL string.

As for the session checking, that looks fine to me. Session data is all stored on the server, the client just sends the session ID that links to it, so they can't spoof specific session values. The only thing someone could do is guess someone else's session ID, then they can hijack their session. There's not much you can do to protect against that.

Barmar
  • 741,623
  • 53
  • 500
  • 612
  • 1
    To add to this in order to prevent session hijacking as Barmar mentioned, try some of the steps/guidelines mentioned in http://stackoverflow.com/questions/3517350/session-hijacking-and-php/3517616#3517616 – drmarvelous Aug 19 '14 at 16:05
  • @drmarvelous - Thanks for the link, i just had a little read up on the documentation site, this should definitely help lock things down ! – Crizly Aug 19 '14 at 16:15
-1

This are in-depth articles about the topic

http://shiflett.org/articles/the-truth-about-sessions, https://security.stackexchange.com/questions/23929/creating-secure-php-sessions.

There is never a 100% security with sessions...

Don't believe the downvoters, the article from Chris Shiflett is invaluable.

See you on another account. ;)

Community
  • 1
  • 1
user32342534
  • 145
  • 6