Is this a safe use of Session Variables?

I used $_SESSION['name'] to handle data from page to page. I mainly used it to keep the user logged in between pages. Within every page, i check if $_SESSION[logged_in'] is true or not. If true, keep user logged in. Otherwise, do something else.

This is how i handle my sessions - basic sample:

<?php

session_start();

if($_SESSION['logged_in'])
{
   //show control panel list
}
else
{
     //show login box. Once user logs in. Once user logs in,
     //fetch userID, username, etc from database. Also set 
     //$_SESSION['logged_in'] = true.
}

?>

Somewhere in between codes i do the following:

SELECT * FROM User WHERE userID = $_SESSION['userID'];

I'm not sure if $_SESSION['userID'] would be accessible by users or not. If its accessible, then the page would be in threat because a user could change the userID manually and get access to others account he/she desires.

I'm not much into security. Please advice! What can i do?

Note: i'm trying to make code as simple as possible. For now, no oop is involved.

Answers


That's pretty good, here are a few other tips for session management:

  1. Do not accept session identifiers from GET/POST variables: Session identifiers in URL (query string, GET variables) or POST variables are not recommended as it simplifies this attack. It is easy to make links on forms which set GET/POST variables.

  2. Regenerate the SID on each request: In PHP use session_regenerate_id(). Every time a user's access level changes, it is necessary to regenerate the session identifier. This means that although an attacker may trick a user into accepting a known SID, the SID will be invalid when the attacker attempts to re-use the SID.


Your code is vulnerable to session fixation and session hijacking attacks. See http://phpsec.org/projects/guide/4.html for more information.

As you build bigger, more involved applications, you will also want to be careful how you handle logging the user out and handling other session-related aspects, such as privilege escalation. Handling sessions and logins safely is a tricky beast.

Implementing secure authentication is hard. Unless you are doing it as an academic exercise, i would strongly recommend using the library provided by your framework, if you are lucky enough to have a good one.

You will also want to consider things such as the following:

  • Do not allow the session id to be forced. [session fixation]
  • When permissions or credentials are changed (e.g. because the user has now logged in or out) then immediately invalidate the session and start a fresh one.
  • Provide a logout feature, and be sure to invalidate the session upon logout.
  • Set the session cookie to HttpOnly -Preferably, require HTTPS and alo set the cookie to secure only.
  • Consider restricting the session validity to include checking some other information that helps to match the user e.g. user-agent. [session hijacking]
  • Always expire sessions after non-use and do not implement "keep me logged in" by reconnecting the user to their old http session.
  • Ensure that all session-related data is destroyed when a session is invalidated, regardless of where it is stored. A new user coming along, may just happen to get assigned a session id that has been used previously. This new session must not have any access to session data that has been set previously against that session id.

$_SESSION is one of the server-side Super Globals. It's not accessible by users or transmitted from your server in any way.


Yes, that is pretty much the right idea.

Here are a couple resources that may help, both with understanding session security and secure programming in general:

http://phpsec.org/projects/guide/4.html http://phpsec.org/projects/guide/


Need Your Help


About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.